-----Original Message-----
From: Charles Mills [mailto:charl
...@mcn.org]
Sent: Tuesday, October 02, 2012 9:03 AM
To: 'openssl-us
...@openssl.org'
Subject: RE: Documentation for TXT_DB errors?
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-us...@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-us...@openssl.org
Automated List Manager majord...@openssl.org
