Bonjour, Hodie pr. Non. Mar. MMV est, ohaya scripsit: > This is the self-signed root CA cert. It is now V3, and has the AKI and > SKI.
Good. >It still has "Digital Signature", as I wasn't sure about what to > do with that on the root CA cert: It's useless, as you'll really use the Root certificate to sporadically sign new sub-CA certificates when the need occurs. But it's also harmless. You'll also have to sign a CRL with this Root, with a large validity period (it can even be as large as the certificate itself, you're allowed to create new CRLs anytime). > Validity > Not Before: Mar 6 07:26:33 2005 GMT > Not After : Mar 7 07:26:29 2013 GMT 1024 bits might be a bit short by 2013. 1024 may not be broken by that date, but the margin will be pretty thin. > X509v3 extensions: > X509v3 Basic Constraints: > CA:TRUE If you want your certificates to be RFC3280 compliant, then this extension MUST be critical. The X.509 standard tells you that if this extension is not critical and not recognized by the software, then this certificate is considered an end-user certificate. Not what you want. So the X.509 standard recommends it to be flagged critical. > This is the subordinated CA cert, signed by the ROOT CA. It is now V3 > also, and has the AKI and SKI. It does not have "Digital Signature": [...] > Not Before: Mar 6 07:30:41 2005 GMT > Not After : Mar 4 07:27:05 2013 GMT Same remark about the key size and the validity period of the certificate. > Subject: [EMAIL PROTECTED], C=US, O=JimDept, OU=JimCo, > CN=ATEST7-SUBROOT-CA > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > RSA Public Key: (1024 bit) > Modulus (1024 bit): > 00:dc:ca:a8:d1:c8:41:91:82:91:fe:d8:c2:8d:2d: > . > <snip> > . > 8c:b1:b2:de:b8:6c:7a:74:67 > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Basic Constraints: critical > CA:TRUE, pathlen:0 Extension flagged critical, and pathlen restricted, good. > X509v3 Key Usage: critical > Certificate Sign, CRL Sign Good. > Finally, just for completeness, this is a client cert that I created > from the subroot CA cert: > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 0a:ba:76:83:46:f0:87:10:18:b0:36:b6:98:5e:24:15 > Signature Algorithm: sha1WithRSAEncryption > Issuer: [EMAIL PROTECTED], C=US, O=JimDept, OU=JimCo, > CN=ATEST7-SUBROOT-CA > Validity > Not Before: Mar 6 07:54:13 2005 GMT > Not After : Mar 1 07:27:49 2013 GMT > Subject: [EMAIL PROTECTED], C=US, O=JimDept, OU=JimCo, > CN=USER30-ATEST7 > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > RSA Public Key: (1024 bit) > Modulus (1024 bit): > 00:aa:b0:98:d9:66:4a:fa:7c:73:28:f3:fc:43:cd: > . > <snip> > . > 53:84:c8:4c:60:f1:48:48:97:15:8e:85:89:5c:ad: > 9a:aa:76:e7:a2:6b:2e:51:43 > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Key Usage: critical > Digital Signature So this certificate can't be used for decrypting messages (emails for example). > Netscape Cert Type: > SSL Client This extension is an old one, and honestly can raise more problems than solutions. It was 'invented' by Netscape before the extendedKeyUsage came and fulfills the same goal (provide usage information with more accuracy than the keyUsage extension alone), but as it isn't standard, applications are free to ignore it. Today, I know that Netscape+Mozilla products use it, Java crypto API does, and maybe OpenSSL recognizes it, but I'm not sure. This extension is checked with others (keyUsage, extendedKeyUsage), also with certificate characteristics (fields of the DN of the subject), and criticality status of those extensions. It can really be a mess. Now, next point. The revocation status. You must either generate CRLs of provide a way to check the revocation status of any certificate (OCSP for example). That means an additional extension can be added to all certificates (but the Root). -- Erwann ABALEA <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
