Re: add extension to an existing (signed) CA certificate
jehan procaccia a écrit : Peter Sylvester a écrit : well, if one takes the standard configuration of openssl, it sets the authoritykey_identifier both the hash and issuer serial, no exception for the root. comment says that pkix recommends that. yes , and the thread you refered me on this list named "Bug in "authorityKeyIdentifier" extension ?" goes in the same direction, altough it is not clear if it concerns THE root CA of a hierarchie or sub-CA and final certs ? on http://marc.info/?l=openssl-dev&m=103640560416217&w=2 I can read "The keyIdentifier is not used, the only valid content for the authorityKeyIdentifier is the issuer's name of the issuer certificate, packed with the issuer's certificate serial number." ... "PKIX recommends the use of the authorityKeyId, and that the French Government says you must to have this extension" Can someone tell me how SSL clients check/verify a 3 level hierarchie ? is it based on extension authorityKeyIdentifier ? At a specific level (1/2/3) it must match keyid ? and /or issuer (DirName humane readable ) ? and/or serial of it's near (just above) parent ? I gave up the idea to resign my root CA ( in order to add it extension CA:TRUE that I foolishly forgot to set initially !) Now, I've created a whole new root-CA and it's 3 level hirrarchy of sub-CA : http://ca.institut-telecom.fr/pki/IT_ROOT_CA2/ However, I realised after creating that new hierarchie, that Level2 sub-CA contains extension AKI with only issuer (DN + serial). you can have a look at it here: http://ca.institut-telecom.fr/pki/IT_CA2/itca2.crt after all discussion regarding AKI in root-CA -> apparently not necessary there, and in sub-CA ...? I still wonder in sub-CA if having AKI with issuer + keyid is recommended, superfluous, or to banish ? regarding my original problem with root-CA not having CA:TRUE, the fact that I had AKI with issuer + keyid in sub-CA prevented me to resign root-CA with a different serial, so in that (rare) case, I would say that AKI+issuer in sub-CA is to banish. However RFC, and book http://david.carella.free.fr/fr/cryptographie/livre-pki-open-source.html apperently recommend it : "AKI must NOT be critical, for root-CA in may be mentioned (however superfluous), in sub-CA it MUST have keyid:always, issuer:always " I'am in doubt in what to do with my new CA hierarchy regarding AKI , please let me know if you think there's problem with it: http://ca.institut-telecom.fr/pki/IT_ROOT_CA2/ Thanks , regards , jehan . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Peter Sylvester a écrit : well, if one takes the standard configuration of openssl, it sets the authoritykey_identifier both the hash and issuer serial, no exception for the root. comment says that pkix recommends that. yes , and the thread you refered me on this list named "Bug in "authorityKeyIdentifier" extension ?" goes in the same direction, altough it is not clear if it concerns THE root CA of a hierarchie or sub-CA and final certs ? on http://marc.info/?l=openssl-dev&m=103640560416217&w=2 I can read "The keyIdentifier is not used, the only valid content for the authorityKeyIdentifier is the issuer's name of the issuer certificate, packed with the issuer's certificate serial number." ... "PKIX recommends the use of the authorityKeyId, and that the French Government says you must to have this extension" Can someone tell me how SSL clients check/verify a 3 level hierarchie ? is it based on extension authorityKeyIdentifier ? At a specific level (1/2/3) it must match keyid ? and /or issuer (DirName humane readable ) ? and/or serial of it's near (just above) parent ? is this procedure clarified somewhere ? Now, back to my original problem: my root CA (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/) doesn't contains extension: X509v3 Basic Constraints: critical CA:TRUE and firefox 3.5 complains aboit it (it is not a CA !) as long as my sub-ca does contain extension authorityKeyIdentifier with keyid/issuer/serial referencing my root CA, I'am stuck with those keyid/issuer/serial when I re-sign root-CA ? ( I re-sign it in order to add CA:TRUE !) any other smooth way to change my root-CA without breaking the chain ? I do not see this recommandation in the rfcs. at least there is a length paragraph for roots to have an exception, and nowhere it is said you must have both link types. an AKI identifies the KEY, not the certificate btw I am not sure that the issuer/serial logic is correctly implementing this in all implementations. It doesn't mean that the verifying CA certificate must have this issuer/combination, any other CA certificate with the same subject DN and same key is also ok. S my 2centimes /P __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Ok, the advice sounds clear ;-) but how could I re-generate my root CA certs without breaking the chain, knowing that the sub-CA does reference root CA serial ? sub-Ca X509 extension Authority Key Identifier is : $ openssl x509 -in /etc/pki/tls/certs/itca.crt -text X509v3 Authority Key Identifier: keyid:5E:9B:F0:D7:DD:87:48:52:99:99:DA:4B:4F:E3:9F:82:DE:16:07:C3 DirName:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr * serial:F9:BF:E3:44:A7:66:2A:A4* Will the chain still work if the new root CA has a different Serial ? Anyhow, when I re-generate the root CA cert from the original one (-in it_root_ca.crt) , I didn't managed to change the Serial :-( , although I did used "-set_serial". Here's the full command I used to re-generate it_root_ca.crt with it's original private key "it_root_ca.key" ( recall the purpose of all these, is to add extensions "Basic Constraints: CA:TRUE" which happens to lack from original it_root_ca.crt I signed in the first place :-( . openssl x509 -signkey it_root_ca.key -set_serial 01 -clrext -extfile opensslIT.cnf -extensions v3_ca -days 5475 -in it_root_ca.crt -out new_it_root_ca10.crt result is http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt which has serial *F9:BF:E3:44:A7:66:2A:A4 and not * 01 as stated by -set_serial in the above command did I missed something ? regards . Kyle Hamilton a écrit : Never, ever, ever, ever, ever under any circumstances issue the same serial number twice. You tried to issue the same serial to both roots -- badbadbadbadbadDONOT. -Kyle H On Tue, Sep 1, 2009 at 8:56 AM, jehan procaccia wrote: jehan procaccia a écrit : I finally found it ! [proca...@anaconda ~] $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/new_it_root_ca10.crt -verify 3 verify depth is 3 CONNECTED(0003) depth=3 /CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr verify return:1 depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify return:1 depth=1 /CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr verify return:1 depth=0 /C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr verify return:1 --- Certificate chain 0 s:/C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr i:/CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr 1 s:/CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr i:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr 2 s:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr 3 s:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr Now everything seems ok with that new root CA: http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt unfortunatly it's not completely finished :-( now on clients where I removed the original root-ca and added the new re-signed root CA ( new_it_root_ca10.crt), I have a issuer/serial problem when accessing a server configured with the "old" root CA. For example going to https://www-cours.it-sudparis.eu/, server which is configured with the original chain and itrootca CA root, firefox complains about : "sec_error_reused_issuer_and_serial" the same with seamonkey client : "Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number" indeed my re-signed root-ca (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt) does have the same serial values as the original itrootca.crt $ openssl x509 -in /etc/pki/tls/certs/new_it_root_ca10.crt -text ... Serial Number: f9:bf:e3:44:a7:66:2a:a4 X509v3 Authority Key Identifier: serial:F9:BF:E3:44:A7:66:2A:A4 ... indeed I supose that when I re-signed my root CA this way: openssl x509 -signkey it_root_ca.key -set_serial 01 -clrext -extfile opensslIT.cnf -extensions v3_ca -days 5475 -in it_root_ca.crt -out new_it_root_ca10.crt Then as long as I call the original -in it_root_ca.crt in the command above , I suspect it extract the serial from it, no matter what I set with "-set_serial" openssl option, it does not set anything new !. then, here's my question, should I set a new serial in order to not conflict with the original one, how can I set it ? if I cannot set a new serial, then it means I should change all my server ca-chai
Re: add extension to an existing (signed) CA certificate
well, if one takes the standard configuration of openssl, it sets the authoritykey_identifier both the hash and issuer serial, no exception for the root. comment says that pkix recommends that. I do not see this recommandation in the rfcs. at least there is a length paragraph for roots to have an exception, and nowhere it is said you must have both link types. an AKI identifies the KEY, not the certificate btw I am not sure that the issuer/serial logic is correctly implementing this in all implementations. It doesn't mean that the verifying CA certificate must have this issuer/combination, any other CA certificate with the same subject DN and same key is also ok. S my 2centimes /P __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Never, ever, ever, ever, ever under any circumstances issue the same serial number twice. You tried to issue the same serial to both roots -- badbadbadbadbadDONOT. -Kyle H On Tue, Sep 1, 2009 at 8:56 AM, jehan procaccia wrote: > jehan procaccia a écrit : >> >> I finally found it ! >> >> [proca...@anaconda ~] >> $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile >> /etc/pki/tls/certs/new_it_root_ca10.crt -verify 3 >> verify depth is 3 >> CONNECTED(0003) >> depth=3 /CN=Institut TELECOM Root class1 Certificate Authority/O=Institut >> TELECOM/C=fr >> verify return:1 >> depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut >> TELECOM/O=Institut TELECOM/C=fr >> verify return:1 >> depth=1 /CN=TELECOM & Management SudParis class3 Certificate >> Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management >> SudParis/C=fr >> verify return:1 >> depth=0 /C=fr/ST=Essonne/L=Evry/O=Telecom et Management >> SudParis/OU=s2ia/CN=svnext.int-evry.fr >> verify return:1 >> --- >> Certificate chain >> 0 s:/C=fr/ST=Essonne/L=Evry/O=Telecom et Management >> SudParis/OU=s2ia/CN=svnext.int-evry.fr >> i:/CN=TELECOM & Management SudParis class3 Certificate >> Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management >> SudParis/C=fr >> 1 s:/CN=TELECOM & Management SudParis class3 Certificate >> Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management >> SudParis/C=fr >> i:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut >> TELECOM/O=Institut TELECOM/C=fr >> 2 s:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut >> TELECOM/O=Institut TELECOM/C=fr >> i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut >> TELECOM/C=fr >> 3 s:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut >> TELECOM/C=fr >> i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut >> TELECOM/C=fr >> >> Now everything seems ok with that new root CA: >> http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt >> > unfortunatly it's not completely finished :-( > now on clients where I removed the original root-ca and added the new > re-signed root CA ( new_it_root_ca10.crt), > I have a issuer/serial problem when accessing a server configured with the > "old" root CA. > > For example going to https://www-cours.it-sudparis.eu/, server which is > configured with the original chain and itrootca CA root, > firefox complains about : > "sec_error_reused_issuer_and_serial" > the same with seamonkey client : > "Your certificate contains the same serial number as another certificate > issued by the certificate authority. Please get a new certificate containing > a unique serial number" > indeed my re-signed root-ca > (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt) does > have the same serial values as the original itrootca.crt > > $ openssl x509 -in /etc/pki/tls/certs/new_it_root_ca10.crt -text > ... > Serial Number: > f9:bf:e3:44:a7:66:2a:a4 > X509v3 Authority Key Identifier: > serial:F9:BF:E3:44:A7:66:2A:A4 > ... > indeed I supose that when I re-signed my root CA this way: > > openssl x509 -signkey it_root_ca.key -set_serial 01 -clrext -extfile > opensslIT.cnf -extensions v3_ca -days 5475 -in it_root_ca.crt -out > new_it_root_ca10.crt > > > Then as long as I call the original > -in it_root_ca.crt > > in the command above , I suspect it extract the serial from it, no matter > what I set with "-set_serial" openssl option, it does not set anything new > !. > > then, here's my question, should I set a new serial in order to not conflict > with the original one, how can I set it ? > if I cannot set a new serial, then it means I should change all my server > ca-chain config in one shot the same day and all my clients browsers > "keystore" :-( ? or is there a soft and clean way to migrate smoothly from > the originalm root-ca and the new one ? > > thanks . > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
jehan procaccia a écrit : I finally found it ! [proca...@anaconda ~] $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/new_it_root_ca10.crt -verify 3 verify depth is 3 CONNECTED(0003) depth=3 /CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr verify return:1 depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify return:1 depth=1 /CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr verify return:1 depth=0 /C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr verify return:1 --- Certificate chain 0 s:/C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr i:/CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr 1 s:/CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr i:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr 2 s:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr 3 s:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr Now everything seems ok with that new root CA: http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt unfortunatly it's not completely finished :-( now on clients where I removed the original root-ca and added the new re-signed root CA ( new_it_root_ca10.crt), I have a issuer/serial problem when accessing a server configured with the "old" root CA. For example going to https://www-cours.it-sudparis.eu/, server which is configured with the original chain and itrootca CA root, firefox complains about : "sec_error_reused_issuer_and_serial" the same with seamonkey client : "Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number" indeed my re-signed root-ca (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt) does have the same serial values as the original itrootca.crt $ openssl x509 -in /etc/pki/tls/certs/new_it_root_ca10.crt -text ... Serial Number: f9:bf:e3:44:a7:66:2a:a4 X509v3 Authority Key Identifier: serial:F9:BF:E3:44:A7:66:2A:A4 ... indeed I supose that when I re-signed my root CA this way: openssl x509 -signkey it_root_ca.key -set_serial 01 -clrext -extfile opensslIT.cnf -extensions v3_ca -days 5475 -in it_root_ca.crt -out new_it_root_ca10.crt Then as long as I call the original -in it_root_ca.crt in the command above , I suspect it extract the serial from it, no matter what I set with "-set_serial" openssl option, it does not set anything new !. then, here's my question, should I set a new serial in order to not conflict with the original one, how can I set it ? if I cannot set a new serial, then it means I should change all my server ca-chain config in one shot the same day and all my clients browsers "keystore" :-( ? or is there a soft and clean way to migrate smoothly from the originalm root-ca and the new one ? thanks . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Jehan PROCACCIA a écrit : Le 28/08/2009 02:57, Patrick Patterson a écrit : Now I removed all my mozilla (firefox, seamonkey ) profiles on my test client that's what you mean by "replacing root CA certificate on your client " ? since I erased profiles (and hence stored ca and servers certificates) now going to https://svnext.it-sudparis.eu/ shows me the svnext server certificate, but when I go to the "details" tab on firefox (add exeption ...) I now see a only 2 level CA hierarchie !? IT_CA (level2) -> Evry_CA (tmsp level3) then the svnext cert, but no trace of IT_ROOT_CA (level1) :-( . Indeed openssl s_client test shows me [proca...@anaconda ~] $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/newitrootca.crt -showcerts CONNECTED(0003) depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify error:num=20:unable to get local issuer certificate verify return:0 It seems that the Class2 (level2) certificate doesn' recognizes my new Class1 (level1) . Do I have to "re-sign" level2 (IT_CA), and then I supose level3 (Evry_CA) , in order to reconstruch a correct chain ? Re-sign those two intermediate CA could be OK, but all the purpose of that thread was not to re-sign my hundreds of servers below level3 CA !. could you confirm me that . Regards . PS: my svnext ssl.conf: SSLCertificateChainFile /etc/pki/tls/certs/new_ca-chain-institut-telecom.crt SSLCACertificateFile /etc/pki/tls/certs/newitrootca.crt SSLCertificateFile /etc/pki/tls/certs/svnext.pem SSLCertificateKeyFile /etc/pki/tls/private/svnext.key Until you do this, all of your clients will continue to use the old client. Also, for those few clients that actually chase AIA, you have to replace the root CA certificate with the new one at the original URL. what means AIA ? I finally found it ! I didn't took the correct original root key/cert pair :-( I took an older the itrootca.crt and itrootca.key which happened to have the same Subject and passphrase, that's what misslead me ... Now that I take the correct pair of itrootca.crt and itrootca.key the command openssl x509 -signkey ca.key -set_serial $SERIAL -clrext -extfile opensslIT.cnf -extensions v3_ca -days 5475 -in ca.crt -out new_it_root_ca10.crt Generate me a correct root cert [proca...@anaconda ~] $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/new_it_root_ca10.crt -verify 3 verify depth is 3 CONNECTED(0003) depth=3 /CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr verify return:1 depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify return:1 depth=1 /CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr verify return:1 depth=0 /C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr verify return:1 --- Certificate chain 0 s:/C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr i:/CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr 1 s:/CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr i:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr 2 s:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr 3 s:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr What gave me a clue, is the KeyID in the extensions the false new one had: X509v3 Subject Key Identifier: DE:AB:5E:42:4D:79:23:7D:5A:FD:8B:9F:A3:99:BE:EC:5C:5D:AE:09 although the level 2 sub CA waited for: X509v3 Authority Key Identifier: keyid:5E:9B:F0:D7:DD:87:48:52:99:99:DA:4B:4F:E3:9F:82:DE:16:07:C3 DirName:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr serial:F9:BF:E3:44:A7:66:2A:A4 Now everything seems ok with that new root CA: http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt Thanks evryone , I hope it correct now . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Le 28/08/2009 02:57, Patrick Patterson a écrit : Jehan PROCACCIA wrote: Le 26/08/2009 22:16, Patrick Patterson a écrit : Hi there: Ok, then in my case $PREFIX is it_root_ca.crt (PKI public cert) and $CAPREFIX it_root_ca.key (PKI private key) . but here's what I get : [pkiitr...@localhost ~/New_IT_ROOT_CA/pki/ca] $ openssl x509 -set_serial 01 -clrext -extfile openssl.cnf -days 3650 -CA it_root_ca.key -CAkey it_root_ca.key -in it_root_ca.crt -out it_root_ca2.crt The simplest way to do this is: openssl x509 -signkey it_root_ca.key -in it_root_ca.crt -clrext -out it_root_ca2.pem -days 3650 -set_serial 01 -extfile openssl.cnf -extensions your_new_ca_extensions Now, what are the contents of your openssl.cnf: You SHOULD (for a Root CA) have a section something similar to: [your_new_ca_extensions] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always basicConstraints = critical,CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign That's it, that's all. OK, I use both of the command I've been given, and now it works :-) openssl x509 -signkey ca.key -set_serial $SERIAL -clrext -extfile opensslIT.cnf -extensions v3_ca -days 5475 -in ca.crt -out new_it_root_ca6.crt or openssl x509 -set_serial $SERIAL -clrext -extfile openssl.cnf -days 5475 -CA it_root_ca.crt -CAkey it_root_ca.key -in it_root_ca.crt -out it_root_ca4.crt My new root CA is at http://www.it-sudparis.eu/pki/IT_MASTER_CA/newitrootca.crt But, now I start to configure an http server reading that new Root CA, but apparently a browser going to https://svnext.it-sudparis.eu/ still shows in the "details" tab, the Root CA (class1) as the "old" one !? Here's the relevant httpd ssl.conf directives SSLCertificateFile /etc/pki/tls/certs/svnext.pem SSLCertificateKeyFile /etc/pki/tls/private/svnext.key SSLCertificateChainFile /etc/pki/tls/certs/new_ca-chain-institut-telecom.crt SSLCACertificateFile /etc/pki/tls/certs/newitrootca.crt ( cat evry_ca.crt ; cat itca.crt ; cat newitrootca.crt )> new_ca-chain-institut-telecom.crt I can check old root CA and New root Ca based on "not after" dates for exemple: in the Browser, not after reads (04/02/2023 16:48:16 GMT) although it should read [r...@svnext /etc/pki/tls/certs] $ openssl x509 -in newitrootca.crt -text | grep "Not After" Not After : Aug 23 09:37:00 2024 GMT I wonder if browsers do read root CA from SSLCACertificateFile or if the deduce it from SSLCertificateFile /etc/pki/tls/certs/svnext.pem !? in that case it means that I will have to re-sign all my servers :-( ? Did you replace the root CA certificate on your client with the new one? Also, did you replace your root CA certificate on the server with the new one? Now I removed all my mozilla (firefox, seamonkey ) profiles on my test client that's what you mean by "replacing root CA certificate on your client " ? since I erased profiles (and hence stored ca and servers certificates) now going to https://svnext.it-sudparis.eu/ shows me the svnext server certificate, but when I go to the "details" tab on firefox (add exeption ...) I now see a only 2 level CA hierarchie !? IT_CA (level2) -> Evry_CA (tmsp level3) then the svnext cert, but no trace of IT_ROOT_CA (level1) :-( . Indeed openssl s_client test shows me [proca...@anaconda ~] $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/newitrootca.crt -showcerts CONNECTED(0003) depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify error:num=20:unable to get local issuer certificate verify return:0 It seems that the Class2 (level2) certificate doesn' recognizes my new Class1 (level1) . Do I have to "re-sign" level2 (IT_CA), and then I supose level3 (Evry_CA) , in order to reconstruch a correct chain ? Re-sign those two intermediate CA could be OK, but all the purpose of that thread was not to re-sign my hundreds of servers below level3 CA !. could you confirm me that . Regards . PS: my svnext ssl.conf: SSLCertificateChainFile /etc/pki/tls/certs/new_ca-chain-institut-telecom.crt SSLCACertificateFile /etc/pki/tls/certs/newitrootca.crt SSLCertificateFile /etc/pki/tls/certs/svnext.pem SSLCertificateKeyFile /etc/pki/tls/private/svnext.key Until you do this, all of your clients will continue to use the old client. Also, for those few clients that actually chase AIA, you have to replace the root CA certificate with the new one at the original URL. what means AIA ?
Re: add extension to an existing (signed) CA certificate
Jehan PROCACCIA wrote: > Le 26/08/2009 22:16, Patrick Patterson a écrit : >> Hi there: >> >> >>> Ok, then in my case $PREFIX is it_root_ca.crt (PKI public cert) and >>> $CAPREFIX it_root_ca.key (PKI private key) . >>> but here's what I get : >>> >>> [pkiitr...@localhost ~/New_IT_ROOT_CA/pki/ca] >>> $ openssl x509 -set_serial 01 -clrext -extfile openssl.cnf -days 3650 >>> -CA it_root_ca.key -CAkey it_root_ca.key -in it_root_ca.crt -out >>> it_root_ca2.crt >>> >> >> The simplest way to do this is: >> >> openssl x509 -signkey it_root_ca.key -in it_root_ca.crt -clrext -out >> it_root_ca2.pem -days 3650 -set_serial 01 -extfile openssl.cnf >> -extensions >> your_new_ca_extensions >> >> Now, what are the contents of your openssl.cnf: >> >> You SHOULD (for a Root CA) have a section something similar to: >> >> [your_new_ca_extensions] >> subjectKeyIdentifier=hash >> authorityKeyIdentifier=keyid:always,issuer:always >> basicConstraints = critical,CA:true >> keyUsage = critical, digitalSignature, cRLSign, keyCertSign >> >> That's it, that's all. >> > OK, I use both of the command I've been given, and now it works :-) > > openssl x509 -signkey ca.key -set_serial $SERIAL -clrext -extfile > opensslIT.cnf -extensions v3_ca -days 5475 -in ca.crt -out > new_it_root_ca6.crt > or > openssl x509 -set_serial $SERIAL -clrext -extfile openssl.cnf -days 5475 > -CA > it_root_ca.crt -CAkey it_root_ca.key -in it_root_ca.crt -out > it_root_ca4.crt > > My new root CA is at > http://www.it-sudparis.eu/pki/IT_MASTER_CA/newitrootca.crt > > But, now I start to configure an http server reading that new Root CA, > but apparently a browser going to > https://svnext.it-sudparis.eu/ still shows in the "details" tab, the > Root CA (class1) as the "old" one !? > > Here's the relevant httpd ssl.conf directives > > SSLCertificateFile /etc/pki/tls/certs/svnext.pem > SSLCertificateKeyFile /etc/pki/tls/private/svnext.key > SSLCertificateChainFile > /etc/pki/tls/certs/new_ca-chain-institut-telecom.crt > SSLCACertificateFile /etc/pki/tls/certs/newitrootca.crt > > ( cat evry_ca.crt ; cat itca.crt ; cat newitrootca.crt ) > > new_ca-chain-institut-telecom.crt > > I can check old root CA and New root Ca based on "not after" dates for > exemple: > in the Browser, not after reads > (04/02/2023 16:48:16 GMT) > although it should read > [r...@svnext /etc/pki/tls/certs] > $ openssl x509 -in newitrootca.crt -text | grep "Not After" > Not After : Aug 23 09:37:00 2024 GMT > > I wonder if browsers do read root CA from SSLCACertificateFile or if the > deduce it from SSLCertificateFile /etc/pki/tls/certs/svnext.pem !? > in that case it means that I will have to re-sign all my servers :-( ? > Did you replace the root CA certificate on your client with the new one? Also, did you replace your root CA certificate on the server with the new one? Until you do this, all of your clients will continue to use the old client. Also, for those few clients that actually chase AIA, you have to replace the root CA certificate with the new one at the original URL. Have fun. Patrick. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Le 26/08/2009 22:16, Patrick Patterson a écrit : Hi there: Ok, then in my case $PREFIX is it_root_ca.crt (PKI public cert) and $CAPREFIX it_root_ca.key (PKI private key) . but here's what I get : [pkiitr...@localhost ~/New_IT_ROOT_CA/pki/ca] $ openssl x509 -set_serial 01 -clrext -extfile openssl.cnf -days 3650 -CA it_root_ca.key -CAkey it_root_ca.key -in it_root_ca.crt -out it_root_ca2.crt The simplest way to do this is: openssl x509 -signkey it_root_ca.key -in it_root_ca.crt -clrext -out it_root_ca2.pem -days 3650 -set_serial 01 -extfile openssl.cnf -extensions your_new_ca_extensions Now, what are the contents of your openssl.cnf: You SHOULD (for a Root CA) have a section something similar to: [your_new_ca_extensions] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always basicConstraints = critical,CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign That's it, that's all. OK, I use both of the command I've been given, and now it works :-) openssl x509 -signkey ca.key -set_serial $SERIAL -clrext -extfile opensslIT.cnf -extensions v3_ca -days 5475 -in ca.crt -out new_it_root_ca6.crt or openssl x509 -set_serial $SERIAL -clrext -extfile openssl.cnf -days 5475 -CA it_root_ca.crt -CAkey it_root_ca.key -in it_root_ca.crt -out it_root_ca4.crt My new root CA is at http://www.it-sudparis.eu/pki/IT_MASTER_CA/newitrootca.crt But, now I start to configure an http server reading that new Root CA, but apparently a browser going to https://svnext.it-sudparis.eu/ still shows in the "details" tab, the Root CA (class1) as the "old" one !? Here's the relevant httpd ssl.conf directives SSLCertificateFile /etc/pki/tls/certs/svnext.pem SSLCertificateKeyFile /etc/pki/tls/private/svnext.key SSLCertificateChainFile /etc/pki/tls/certs/new_ca-chain-institut-telecom.crt SSLCACertificateFile /etc/pki/tls/certs/newitrootca.crt ( cat evry_ca.crt ; cat itca.crt ; cat newitrootca.crt ) > new_ca-chain-institut-telecom.crt I can check old root CA and New root Ca based on "not after" dates for exemple: in the Browser, not after reads (04/02/2023 16:48:16 GMT) although it should read [r...@svnext /etc/pki/tls/certs] $ openssl x509 -in newitrootca.crt -text | grep "Not After" Not After : Aug 23 09:37:00 2024 GMT I wonder if browsers do read root CA from SSLCACertificateFile or if the deduce it from SSLCertificateFile /etc/pki/tls/certs/svnext.pem !? in that case it means that I will have to re-sign all my servers :-( ? also, If I test my server with openssl s_client $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/newitrootca.crt -showcerts CONNECTED(0003) depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify error:num=20:unable to get local issuer certificate verify return:0 Same request with -CAfile pointing to the "old/original" itrootca.crt : [proca...@anaconda ~] $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/itrootca.crt -showcerts CONNECTED(0003) depth=3 /CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr verify return:1 depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify return:1 depth=1 /CN=TELECOM & Management SudParis class3 Certificate Authority/OU=TELECOM & Management SudParis/O=TELECOM & Management SudParis/C=fr verify return:1 depth=0 /C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr verify return:1 I'am confuse, do I have to resign other certificates (2level sub-CA, 3rd level sub-sub-CA, hundreds of servers ... :-( ) , or I misconfigured my apache server !? PS: recall my hierarchie IT_ROOT_CA | -IT_CA-- | | | Evry_CAParis_CA Brest_CA | || www imap
Re: add extension to an existing (signed) CA certificate
Hi there: > > Ok, then in my case $PREFIX is it_root_ca.crt (PKI public cert) and > $CAPREFIX it_root_ca.key (PKI private key) . > but here's what I get : > > [pkiitr...@localhost ~/New_IT_ROOT_CA/pki/ca] > $ openssl x509 -set_serial 01 -clrext -extfile openssl.cnf -days 3650 > -CA it_root_ca.key -CAkey it_root_ca.key -in it_root_ca.crt -out > it_root_ca2.crt The simplest way to do this is: openssl x509 -signkey it_root_ca.key -in it_root_ca.crt -clrext -out it_root_ca2.pem -days 3650 -set_serial 01 -extfile openssl.cnf -extensions your_new_ca_extensions Now, what are the contents of your openssl.cnf: You SHOULD (for a Root CA) have a section something similar to: [your_new_ca_extensions] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always basicConstraints = critical,CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign That's it, that's all. Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
On 08/26/2009 04:24 PM, Peter Sylvester wrote: Jehan PROCACCIA wrote: Le 26/08/2009 12:17, Peter Sylvester a écrit : OK, then how do I re-issue my root CA certificate with my already existing ca.key ? If I could have a sample commande line for openssl it would help me . something like OPENSSL x509 -set_serial $SERIAL -clrext -extfile CA-EXTENSION.prm -days $DURATION -CA $CAPREFIX-ca.cacert -CAkey $CAPREFIX-ca.key -in $PREFIX-ca.crt -out $PREFIX-ca.der -outform der -sha256 thanks for the sample command line, howerver I don't get it clearly ... what are $CAPREFIX-ca.cacert and $PREFIX-ca.crt !? the -extfile CA-EXTENSION.prm could be a localy modified openssl.cnf ? then the -clrext isn't clear to me "delete extensions before signing and input certificate", in the 1st place , I do want to add extensions, why ask openssl to delete them !? All $things are "variables": $PREFIX is the cert that you want to modify (a copy or your root cert) $CAPREFIX the key (and cert) you want to sign with (cert is used to become issuer), agin your root cert and key. CA_EXTENSION.prm is a complete set of extension that you want to have with the initial section containing extensions=whateverlistofextensions. The original input cert contains extensions, they are "ignored" with the -clrext. Only the extensions from the config file are taken. Ok, then in my case $PREFIX is it_root_ca.crt (PKI public cert) and $CAPREFIX it_root_ca.key (PKI private key) . but here's what I get : [pkiitr...@localhost ~/New_IT_ROOT_CA/pki/ca] $ openssl x509 -set_serial 01 -clrext -extfile openssl.cnf -days 3650 -CA it_root_ca.key -CAkey it_root_ca.key -in it_root_ca.crt -out it_root_ca2.crt unable to load certificate 4869:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:644:Expecting: TRUSTED CERTIFICATE did I misunderstood you ? here's my environement: [pkiitr...@localhost ~/New_IT_ROOT_CA/pki/ca] $ ls -l total 140 drwxrwxr-x 3 pkiitroot pkiitroot 4096 Jul 15 17:59 certs -rw-rw-r-- 1 pkiitroot pkiitroot0 Jul 15 18:00 index.txt -rw-rw-r-- 1 pkiitroot pkiitroot 2858 Jul 15 20:13 it_root_ca.crt -rw-rw-r-- 1 pkiitroot pkiitroot 3311 Jul 15 20:13 it_root_ca.key drwxrwxr-x 2 pkiitroot pkiitroot 4096 Jul 15 17:59 newcerts -rw-r--r-- 1 pkiitroot pkiitroot 9873 Jul 16 03:19 openssl.cnf drwxrwxr-x 2 pkiitroot pkiitroot 4096 Jul 15 17:59 private -rw-rw-r-- 1 pkiitroot pkiitroot3 Jul 15 18:00 serial $ rpm -q openssl openssl-0.9.8b-8.3.el5_0.2 Thanks . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Jehan PROCACCIA wrote: Le 26/08/2009 12:17, Peter Sylvester a écrit : OK, then how do I re-issue my root CA certificate with my already existing ca.key ? If I could have a sample commande line for openssl it would help me . something like OPENSSL x509 -set_serial $SERIAL -clrext -extfile CA-EXTENSION.prm -days $DURATION -CA $CAPREFIX-ca.cacert -CAkey $CAPREFIX-ca.key -in $PREFIX-ca.crt -out $PREFIX-ca.der -outform der -sha256 thanks for the sample command line, howerver I don't get it clearly ... what are $CAPREFIX-ca.cacert and $PREFIX-ca.crt !? the -extfile CA-EXTENSION.prm could be a localy modified openssl.cnf ? then the -clrext isn't clear to me "delete extensions before signing and input certificate", in the 1st place , I do want to add extensions, why ask openssl to delete them !? All $things are "variables": $PREFIX is the cert that you want to modify (a copy or your root cert) $CAPREFIX the key (and cert) you want to sign with (cert is used to become issuer), agin your root cert and key. CA_EXTENSION.prm is a complete set of extension that you want to have with the initial section containing extensions=whateverlistofextensions. The original input cert contains extensions, they are "ignored" with the -clrext. Only the extensions from the config file are taken. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Le 26/08/2009 12:17, Peter Sylvester a écrit : OK, then how do I re-issue my root CA certificate with my already existing ca.key ? If I could have a sample commande line for openssl it would help me . something like OPENSSL x509 -set_serial $SERIAL -clrext -extfile CA-EXTENSION.prm -days $DURATION -CA $CAPREFIX-ca.cacert -CAkey $CAPREFIX-ca.key -in $PREFIX-ca.crt -out $PREFIX-ca.der -outform der -sha256 thanks for the sample command line, howerver I don't get it clearly ... what are $CAPREFIX-ca.cacert and $PREFIX-ca.crt !? the -extfile CA-EXTENSION.prm could be a localy modified openssl.cnf ? then the -clrext isn't clear to me "delete extensions before signing and input certificate", in the 1st place , I do want to add extensions, why ask openssl to delete them !? Let me recall my needs: Here's what I have: it_root_ca.crt (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/itrootca.crt) the corresponding it_root_ca.key, I want to re-sign it_root_ca.crt in order to add extensions, but need to re-sign it with it_root_ca.key so that my PKI chain (sub CAs) and SSL servers certs below still works as usual. Thanks a lot for your help . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
OK, then how do I re-issue my root CA certificate with my already existing ca.key ? If I could have a sample commande line for openssl it would help me . something like OPENSSL x509 -set_serial $SERIAL -clrext -extfile CA-EXTENSION.prm -days $DURATION -CA $CAPREFIX-ca.cacert -CAkey $CAPREFIX-ca.key -in $PREFIX-ca.crt -out $PREFIX-ca.der -outform der -sha256 OK, I will coorect these extensions with an appropiate openssl.cnf , but I don't understand why there shouldn't be a certificatePolicy section in my master root_CA !? because it is ignored anyway in a trust anchor. A policy document specifies mainly what you may put into end entity certificates that are created under a PC (and maybe what a certifying CA for your CA may put into a CA cert) If you put it into intermediate CAs, they are filters indicating what that CA can create, whether this is actually tested is still another story. I though that it was "mandatory", meaning that it points to the place where our PKI policy is defined . Depending on what specification? You probably may want to put it into end entities. It does not hurt (much). Whether you want to put filters into CA certificates, is another story. For oid 1.1.1.1.1, years ago we did reserved a IANA oid number (1.3.6.1.4.1.7391 ) we used 7391.2 for ldap, 7391.1 for snmp, is there a recommandation for certificates or 7391.3 would be fine ? As long as "you" own 7391, you organise the name space as you like and there is no (technical) semantics related to such a hierarchie. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Le 25/08/2009 20:09, Patrick Patterson a écrit : The only way to add this extension to your root cert is to re-issue your Root CA certificate (you can use the same private keys, so you wouldn't have to change or re-do any of the other certificates in your trust chain, as long as your Certificate Policy allows this). OK, then how do I re-issue my root CA certificate with my already existing ca.key ? I only see example to create a CA self signed from scratch (both key and certs), but not from an already existing key : openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem \ -out cacert.pem -days 3650 -config ./openssl.cnf where should I introduce my ca.key ? If I could have a sample commande line for openssl it would help me . Now, while you are at it, you may want to fix up a couple of things: First of all, it is generally considered to be ill advised to create a certificatePolicy section in a Root CA. This is in case you ever change the assurance levels / certificate Policy OID that your PKI issues (among other reasons - see RFC3280 and RFC5280). Second, I doubt your organisation is authoritative for the OID arc 1.1.1.1.1 - from what documentation I can find, the 1.1 arc is used for examples, and shouldn't be used in production. You should have your organisation register with IANA to be issued its own correct OID arc (or, I think the French Government maintains an arc under their country arc for organisations and companies in that country). Also, since Root CA Certificates are not revoked by CRL (Please see RFC3280/RFC5280 for trust anchor verification), it is not considered good practice to have CRL DP in the root cert. And, having an AIA that points to itself is simply not that great an idea :) OK, I will coorect these extensions with an appropiate openssl.cnf , but I don't understand why there shouldn't be a certificatePolicy section in my master root_CA !? I though that it was "mandatory", meaning that it points to the place where our PKI policy is defined . For oid 1.1.1.1.1, years ago we did reserved a IANA oid number (1.3.6.1.4.1.7391 ) we used 7391.2 for ldap, 7391.1 for snmp, is there a recommandation for certificates or 7391.3 would be fine ? My "Master" root CA (IT_ROOT_CA) signed a intermediate (sub IT_CA) CA, that finally signed 3rd level local schools CA (Paris_CA etc .. those finally signed servers ...), then that "Master" root CA should (?) maintained a CRL for the Sub CA (2nd level) certificate, no ? IT_ROOT_CA | -IT_CA-- | | | Evry_CAParis_CA Brest_CA | || www imap Regards . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
If you want to get an OID branch, you can get one by applying for a "Private Enterprise Number" from the IANA, at http://pen.iana.org/pen/PenApplication.page . You will be assigned a number. This number will show up at http://www.iana.org/assignments/enterprise-numbers . This becomes your OID -- 1.3.6.1.4.1.. You can delegate anything you want from it, to any depth you want, to any level of ludicrosity you want. But, you can't do that in a number space that you do not already own. -Kyle H On Tue, Aug 25, 2009 at 11:50 AM, Peter Sylvester wrote: > >> Second, I doubt your organisation is authoritative for the OID arc >> 1.1.1.1.1 - from what documentation I can find, the 1.1 arc is used for >> examples, and shouldn't be used in production. You should have your >> organisation register with IANA to be issued its own correct OID arc (or, I >> think the French Government maintains an arc under their country arc for >> organisations and companies in that country). > > Afnor maintains at least the arc under 1.2.250.1, registration > required. > > I don't know whether 2.16.250 is actually in use. > > But there is a simpler arc: > 1.3.2 followed by the 'siren' or 'siret' number, i.e. > an identification of an organisation, > no additional registration necessary. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Second, I doubt your organisation is authoritative for the OID arc 1.1.1.1.1 - from what documentation I can find, the 1.1 arc is used for examples, and shouldn't be used in production. You should have your organisation register with IANA to be issued its own correct OID arc (or, I think the French Government maintains an arc under their country arc for organisations and companies in that country). Afnor maintains at least the arc under 1.2.250.1, registration required. I don't know whether 2.16.250 is actually in use. But there is a simpler arc: 1.3.2 followed by the 'siren' or 'siret' number, i.e. an identification of an organisation, no additional registration necessary. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Hello Jehan: On August 24, 2009 10:15:51 am jehan procaccia wrote: > Hello, > > since Firefox 3.5 apparently doesn't accept Root CA self signed > certificate which doesn't contain correct extensions (Basic Constraints: > CA:TRUE) > I wonder how I can add these extensions to my already existing and self > signed Root CA : > http://ca.institut-telecom.fr/pki/IT_MASTER_CA/itrootca.crt > The short answer is - you can't 'ADD' an extension to a signed certificate. What you would have to do is to re-do your key ceremony and re-issue your root certificate, following the process outlined for certificate modification in your CP. > My second level (intermediate; > http://ca.institut-telecom.fr/pki/IT_CA/itca.crt) CA does contain these > extensions: > > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > Netscape Cert Type: > SSL CA, S/MIME CA, Object Signing CA > > And it works fine with them. > > Apparently that was the case of verisign CA back to V1 certificate also .. V1 certificates don't have an extensions section, so this isn't a problem. > So I suspect and hope that I can change, alter, my running root CA > certificate !?, can you tell me how ? As I said above, you can't alter a signed structure - that's why you sign it - to prevent anyone from altering it. The only way to add this extension to your root cert is to re-issue your Root CA certificate (you can use the same private keys, so you wouldn't have to change or re-do any of the other certificates in your trust chain, as long as your Certificate Policy allows this). Then, you just have to re-deploy this new certificate out to all of your relying parties - of course, you would have had to do that if you had been able to alter your existing Root CA certificate, so the process is no different. Now, while you are at it, you may want to fix up a couple of things: First of all, it is generally considered to be ill advised to create a certificatePolicy section in a Root CA. This is in case you ever change the assurance levels / certificate Policy OID that your PKI issues (among other reasons - see RFC3280 and RFC5280). Second, I doubt your organisation is authoritative for the OID arc 1.1.1.1.1 - from what documentation I can find, the 1.1 arc is used for examples, and shouldn't be used in production. You should have your organisation register with IANA to be issued its own correct OID arc (or, I think the French Government maintains an arc under their country arc for organisations and companies in that country). Also, since Root CA Certificates are not revoked by CRL (Please see RFC3280/RFC5280 for trust anchor verification), it is not considered good practice to have CRL DP in the root cert. And, having an AIA that points to itself is simply not that great an idea :) Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
add extension to an existing (signed) CA certificate
Hello, since Firefox 3.5 apparently doesn't accept Root CA self signed certificate which doesn't contain correct extensions (Basic Constraints: CA:TRUE) I wonder how I can add these extensions to my already existing and self signed Root CA : http://ca.institut-telecom.fr/pki/IT_MASTER_CA/itrootca.crt My second level (intermediate; http://ca.institut-telecom.fr/pki/IT_CA/itca.crt) CA does contain these extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA And it works fine with them. Apparently that was the case of verisign CA back to V1 certificate also .. http://www.drh-consultancy.demon.co.uk/nscertype.html http://unitstep.net/blog/2009/03/16/using-the-basic-constraints-extension-in-x509-v3-certificates-for-intermediate-cas/ From http://www.openssl.org/docs/apps/x509v3_config.html , I read DESCRIPTION Several of the OpenSSL utilities can add extensions to a certificate or certificate request based on the contents of a configuration file. So I suspect and hope that I can change, alter, my running root CA certificate !?, can you tell me how ? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
