Dave, as always, thanks. > Unlike most(?) other modules in openssl, txt_db does NOT use the ERR_ module with its error strings
I love OpenSSL and I'm not going to tell you how to run your organization but better documentation would probably mean both wider acceptance and fewer dumb questions from folks like me! > Does any line in index.txt have col 3 (serial) 1C? No. Here is a cut and paste of the entire left hand side of index.txt. R 130821124505Z 120822123411Z 0B unknown /CN=C R 130822123506Z 120822124611Z 0C unknown /CN=C V 130822124721Z 0D unknown /CN=Charles Mills R 130822125501Z 120823201015Z 0E unknown /CN=C R 130822135246Z 120822185456Z 0F unknown /CN=C R 130822185636Z 120822190409Z 10 unknown /CN=C R 130822190502Z 120823201600Z 11 unknown /CN=C R 130823201708Z 120824133410Z 12 unknown /CN=C R 130824133506Z 120824145025Z 13 unknown /CN=C R 130824134844Z 120824135333Z 14 unknown /CN=C V 130824135429Z 15 unknown /CN=Charles Mills V 130824152620Z 16 unknown /CN=Charles Mills R 130830225706Z 120830235325Z 17 unknown /CN=C R 130831000017Z 120831231148Z 18 unknown /CN=C R 130831233626Z 120904174701Z 19 unknown /CN=C R 130905130939Z 120905182554Z 1A unknown /CN=C R 130912152715Z 120912155806Z 1B unknown /CN=C R 120919161159Z 121001143321Z 93E150296A86E7C7 > you should have 27 or 28 (respectively) lines in index.txt Early on in my use of OpenSSL, when I (a.) understood even less than I do now and (b.) issued lots of "practice" certificates I "solved" the duplicate certificate problem by repeatedly deleting and re-creating index.txt. My bad. Perhaps I should both delete it ONE more time and reset serial to 00? This is a total playpen situation. I have no pretense of being any sort of "real" CA at this time. > The usual name for the serial file is just serial no .txt Definitely serial.txt. Not sure how that happened. Something in the Win32 pre-built distribution that I got? > If the file doesn't exist this can't work. Was the error nonexistent file, or something else, and if so what? Non-existent file. Was not sure if revoke started from the file or from the index. > Did you configure that on? Config file in use says unique_subject = no > Further, there is no requirement the subject DN be unique. Wow, I ran into lots of trouble with that issue. That's how I got into re-creating the index file (which I now know was wrong, but nonetheless that is why I did it). Any idea why I would have had certificate requests rejected as duplicates then? > Aside: I'm pretty sure you don't need the .nnn i.e. .2 here, since openssl treats subjectAltName as one Hmmm. It's working so I don't think I'll touch it. I know it took a lot of hacking to get it to work. Again, may I repeat my plea for documentation? Why do open source projects attract plenty of coders but not tech writers? Aren't there tech writers who would love to make a contribution to open source? thanks and take care, Charles -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Monday, October 01, 2012 6:02 PM To: openssl-users@openssl.org Subject: RE: Documentation for TXT_DB errors? > From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills > Sent: Monday, 01 October, 2012 10:12 > Is there specific documentation anywhere for TXT_DB errors? > AFAIK only $sourcetree/crypto/txt_db/txt_db.h Unlike most(?) other modules in openssl, txt_db does NOT use the ERR_ module with its error strings capability; bummer. > I'm not a total newbie at this but I am not an expert. I have issued > server certificates before but now I am stuck on a TXT_DB error 2. > 2 is DB_ERROR_INDEX_CLASH . > serial.txt exists and contains 1C. index.txt exists and contains 17 > (decimal) lines. > Does any line in index.txt have col 3 (serial) 1C? All certs from a CA (at least under a given CA key+cert if you chain with AKI, as is generally best practice but optional in openssl) must have unique serials, and openssl 'ca' enforces this with an in-memory index on data in file (normally and a bit misleadingly) index.txt, in addition to using file serial which if not interfered with assigns sequential thus unique values. If serial(.txt?) started from 00 or 01, and only 'ca' updated it, and you didn't delete any lines from index.txt or replace that with a copy/version that is missing lines (like a backup), you should have 27 or 28 (respectively) lines in index.txt, for each serial value through hex 1B in sequence. The usual name for the serial file is just serial no .txt. I assume either this is a typo or you changed the config so that serial.txt is actually being used. If not, look at the file that is actually being used. > Unless I am confused the CN I am trying to issue for is unique. A > revoke for the_cn_name.PEM fails. However some of the additional DNS > in the certificate are not unique. Is that a problem? In other words, > I am trying to issue foo.PEM for CN=foo. foo.PEM does not exist and > O=foo does not appear in index.txt. But I am trying to issue the > certificate with DNS.2=bar. I may already have outstanding unrevoked > certificates with DNS.2=bar. Is that a problem? > You say revoke (I assume ca -revoke) the_cn_name.PEM 'fails' but then you say CN=foo and foo.PEM does not exist. -revoke uses existing cert file(s) to determine serial, and check subject. If the file doesn't exist this can't work. Was the error nonexistent file, or something else, and if so what? A cert's subject (or other) DN (Distinguished Name) can have multiple attributes; CN (Common Name) is the only one important for SSL or at least HTTPS server, and maybe all you are using. Specifically, do you mean a subject of /CN=foo or /O=foo ? Those are *different* DNs as far as X.509 is concerned, but the latter is not useful for an SSL server cert. Further, there is no requirement the subject DN be unique. You can quite reasonably have multiple certs for one subject, from the same CA (with different serials) or different CAs. It may sometimes be confusing and undesirable, and openssl 'ca' has an option to reject it (within one CA) but not by default. Did you configure that on? The *issuer* DN, i.e. the *CA* DN, should be unique, to allow openssl to verify, or auto-chain, a child cert. If you only created yourself one CA key+cert, it is necessarily unique. Assuming you mean DNS.2 *in subjectAltName aka SAN*, SAN values (also) don't need to be unique and aren't checked. I guess .2=bar and (.1)=subject=foo, another good practice not enforced by openssl? Aside: I'm pretty sure you don't need the .nnn i.e. .2 here, since openssl treats subjectAltName as one attribute containing multiple values, not multiple attributes that must be combined. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
