Re: add extension to an existing (signed) CA certificate
Jehan PROCACCIA
> 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_CA Paris_CA Brest_CA
|
|------------|
www imap ....
Regards .
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Peter Sylvester
> OK, then how do I re-issue my root CA certificate with my already
> existing ca.key ?
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.
Jehan PROCACCIA
>
>> 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
>
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 .
Peter Sylvester
> 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.
jehan procaccia
$CAPREFIX it_root_ca.key (PKI private key) .
but here's what I get :
[pkiitroot@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:
[pkiitroot@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 pkiitroot 0 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 pkiitroot 3 Jul 15 18:00 serial
$ rpm -q openssl
openssl-0.9.8b-8.3.el5_0.2
Thanks .
Patrick Patterson
>
> 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 :
>
> [pkiitroot@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
Jehan PROCACCIA
--------------020309040706040906040008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 :
>>
>> [pkiitroot@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
[root@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(00000003)
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 :
[procacci@anaconda ~]
$ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile
/etc/pki/tls/certs/itrootca.crt -showcerts
CONNECTED(00000003)
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_CA Paris_CA Brest_CA
|
|------------|
www imap ....
--------------020309040706040906040008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Le 26/08/2009 22:16, Patrick Patterson a écrit :
<blockquote cite="mid:200908261616.1...@carillon.ca"
type="cite">
<pre wrap="">Hi there:
</pre>
<blockquote type="cite">
<pre wrap="">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 :
[pkiitroot@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
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
OK, I use both of the command I've been given, and now it works :-) <br>
<br>
openssl x509 -signkey ca.key -set_serial $SERIAL -clrext -extfile<br>
opensslIT.cnf -extensions v3_ca -days 5475 -in ca.crt -out
new_it_root_ca6.crt<br>
or<br>
openssl x509 -set_serial $SERIAL -clrext -extfile openssl.cnf -days
5475 -CA<br>
it_root_ca.crt -CAkey it_root_ca.key -in it_root_ca.crt -out
it_root_ca4.crt<br>
<br>
My new root CA is at
<a class="moz-txt-link-freetext" href="http://www.it-sudparis.eu/pki/IT_MASTER_CA/newitrootca.crt">http://www.it-sudparis.eu/pki/IT_MASTER_CA/newitrootca.crt</a><br>
<br>
But, now I start to configure an http server reading that new Root CA,
but apparently a browser going to <br>
<a class="moz-txt-link-freetext" href="https://svnext.it-sudparis.eu/">https://svnext.it-sudparis.eu/</a> still shows in the "details" tab, the
Root CA (class1) as the "old" one !?<br>
<br>
Here's the relevant httpd ssl.conf directives<br>
<br>
SSLCertificateFile /etc/pki/tls/certs/svnext.pem<br>
SSLCertificateKeyFile /etc/pki/tls/private/svnext.key<br>
SSLCertificateChainFile
/etc/pki/tls/certs/new_ca-chain-institut-telecom.crt<br>
SSLCACertificateFile /etc/pki/tls/certs/newitrootca.crt<br>
<br>
( cat evry_ca.crt ; cat itca.crt ; cat newitrootca.crt ) >
new_ca-chain-institut-telecom.crt<br>
<br>
I can check old root CA and New root Ca based on "not after" dates for
exemple:<br>
in the Browser, not after reads<br>
(04/02/2023 16:48:16 GMT)<br>
although it should read <br>
[root@svnext /etc/pki/tls/certs]<br>
$ openssl x509 -in newitrootca.crt -text | grep "Not After"<br>
Not After : Aug 23 09:37:00 2024 GMT<br>
<br>
I wonder if browsers do read root CA from SSLCACertificateFile or if
the deduce it from SSLCertificateFile /etc/pki/tls/certs/svnext.pem !?<br>
in that case it means that I will have to re-sign all my servers :-( ?<br>
<br>
also, If I test my server with openssl s_client<br>
<br>
$ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile
/etc/pki/tls/certs/newitrootca.crt -showcerts<br>
CONNECTED(00000003)<br>
depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut
TELECOM/O=Institut TELECOM/C=fr<br>
verify error:num=20:unable to get local issuer certificate<br>
verify return:0<br>
<br>
Same request with -CAfile pointing to the "old/original" itrootca.crt :<br>
<br>
[procacci@anaconda ~]<br>
$ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile
/etc/pki/tls/certs/itrootca.crt -showcerts<br>
CONNECTED(00000003)<br>
depth=3 /CN=Institut TELECOM Root class1 Certificate
Authority/O=Institut TELECOM/C=fr<br>
verify return:1<br>
depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut
TELECOM/O=Institut TELECOM/C=fr<br>
verify return:1<br>
depth=1 /CN=TELECOM & Management SudParis class3 Certificate
Authority/OU=TELECOM & Management SudParis/O=TELECOM &
Management SudParis/C=fr<br>
verify return:1<br>
depth=0 /C=fr/ST=Essonne/L=Evry/O=Telecom et Management
SudParis/OU=s2ia/CN=svnext.int-evry.fr<br>
verify return:1<br>
<br>
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 !?<br>
<br>
PS: recall my hierarchie<br>
IT_ROOT_CA
<br>
|
<br>
-------------IT_CA--------------
<br>
| | |
<br>
Evry_CA Paris_CA Brest_CA
<br>
|
<br>
|------------|
<br>
www imap ....
<br>
<br>
<br>
</body>
</html>
--------------020309040706040906040008--
Patrick Patterson
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.
Jehan PROCACCIA
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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
[procacci@anaconda ~]
$ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile
/etc/pki/tls/certs/newitrootca.crt -showcerts
CONNECTED(00000003)
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 ?
>
--------------090305000501080805010503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Le 28/08/2009 02:57, Patrick Patterson a écrit :
<blockquote cite="mid:4A972B84...@carillon.ca" type="cite">
<pre wrap="">Jehan PROCACCIA wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Le 26/08/2009 22:16, Patrick Patterson a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">Hi there:
</pre>
<blockquote type="cite">
<pre wrap="">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 :
[pkiitroot@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
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-freetext" href="http://www.it-sudparis.eu/pki/IT_MASTER_CA/newitrootca.crt">http://www.it-sudparis.eu/pki/IT_MASTER_CA/newitrootca.crt</a>
But, now I start to configure an http server reading that new Root CA,
but apparently a browser going to
<a class="moz-txt-link-freetext" href="https://svnext.it-sudparis.eu/">https://svnext.it-sudparis.eu/</a> 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
[root@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 :-( ?
</pre>
</blockquote>
<pre wrap=""><!---->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?
</pre>
</blockquote>
Now I removed all my mozilla (firefox, seamonkey ) profiles on my test
client<br>
that's what you mean by "replacing root CA certificate on your client
" ?<br>
since I erased profiles (and hence stored ca and servers certificates)
now <br>
going to <a class="moz-txt-link-freetext" href="https://svnext.it-sudparis.eu/">https://svnext.it-sudparis.eu/</a> shows me the svnext server
certificate, <br>
but when I go to the "details" tab on firefox (add exeption ...) I now
see a only 2 level CA hierarchie !?<br>
IT_CA (level2) -> Evry_CA (tmsp level3) then the svnext cert, but no
trace of IT_ROOT_CA (level1) :-( .<br>
<br>
Indeed openssl s_client test shows me <br>
<br>
[procacci@anaconda ~]<br>
$ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile
/etc/pki/tls/certs/newitrootca.crt -showcerts<br>
CONNECTED(00000003)<br>
depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut
TELECOM/O=Institut TELECOM/C=fr<br>
verify error:num=20:unable to get local issuer certificate<br>
verify return:0<br>
<br>
It seems that the Class2 (level2) certificate doesn' recognizes my new
Class1 (level1) .<br>
Do I have to "re-sign" level2 (IT_CA), and then I supose level3
(Evry_CA) , in order to reconstruch a correct chain ?<br>
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 .<br>
<br>
Regards .<br>
<br>
<br>
PS: my svnext ssl.conf:<br>
<br>
SSLCertificateChainFile
/etc/pki/tls/certs/new_ca-chain-institut-telecom.crt<br>
SSLCACertificateFile /etc/pki/tls/certs/newitrootca.crt<br>
SSLCertificateFile /etc/pki/tls/certs/svnext.pem<br>
SSLCertificateKeyFile /etc/pki/tls/private/svnext.key<br>
<br>
<blockquote cite="mid:4A972B84...@carillon.ca" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
what means AIA ?<br>
<blockquote cite="mid:4A972B84...@carillon.ca" type="cite">
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>
--------------090305000501080805010503--
jehan procaccia
> Le 28/08/2009 02:57, Patrick Patterson a �crit : Now I removed all my
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
[procacci@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(00000003)
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 .
jehan procaccia
> I finally found it !
>
> http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt
>
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 .
Kyle Hamilton
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<jehan.p...@it-sudparis.eu> wrote:
> jehan procaccia a =C3=A9crit :
>>
>> I finally found it !
>>
>> [procacci@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(00000003)
>> depth=3D3 /CN=3DInstitut TELECOM Root class1 Certificate Authority/O=3DI=
nstitut
>> TELECOM/C=3Dfr
>> verify return:1
>> depth=3D2 /CN=3DInstitut TELECOM class2 Certificate Authority/OU=3DInsti=
tut
>> TELECOM/O=3DInstitut TELECOM/C=3Dfr
>> verify return:1
>> depth=3D1 /CN=3DTELECOM & Management SudParis class3 Certificate
>> Authority/OU=3DTELECOM & Management SudParis/O=3DTELECOM & Management
>> SudParis/C=3Dfr
>> verify return:1
>> depth=3D0 /C=3Dfr/ST=3DEssonne/L=3DEvry/O=3DTelecom et Management
>> SudParis/OU=3Ds2ia/CN=3Dsvnext.int-evry.fr
>> verify return:1
>> ---
>> Certificate chain
>> 0 s:/C=3Dfr/ST=3DEssonne/L=3DEvry/O=3DTelecom et Management
>> SudParis/OU=3Ds2ia/CN=3Dsvnext.int-evry.fr
>> i:/CN=3DTELECOM & Management SudParis class3 Certificate
>> Authority/OU=3DTELECOM & Management SudParis/O=3DTELECOM & Management
>> SudParis/C=3Dfr
>> 1 s:/CN=3DTELECOM & Management SudParis class3 Certificate
>> Authority/OU=3DTELECOM & Management SudParis/O=3DTELECOM & Management
>> SudParis/C=3Dfr
>> i:/CN=3DInstitut TELECOM class2 Certificate Authority/OU=3DInstitut
>> TELECOM/O=3DInstitut TELECOM/C=3Dfr
>> 2 s:/CN=3DInstitut TELECOM class2 Certificate Authority/OU=3DInstitut
>> TELECOM/O=3DInstitut TELECOM/C=3Dfr
>> i:/CN=3DInstitut TELECOM Root class1 Certificate Authority/O=3DInstitut
>> TELECOM/C=3Dfr
>> 3 s:/CN=3DInstitut TELECOM Root class1 Certificate Authority/O=3DInstitu=
t
>> TELECOM/C=3Dfr
>> i:/CN=3DInstitut TELECOM Root class1 Certificate Authority/O=3DInstitut
>> TELECOM/C=3Dfr
>>
>> 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 th=
e
> "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 =C2=A0number as another certif=
icate
> issued by the certificate authority. Please get a new certificate contain=
ing
> a unique serial number"
> indeed my re-signed root-ca
> (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt) doe=
s
> 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:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f9:bf:e3:44:a7:66:2a:a4
> X509v3 Authority Key Identifier:
> =C2=A0 =C2=A0 =C2=A0 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 =C2=A0"-set_serial" openssl option, it does not set anyth=
ing new
> !.
>
> then, here's my question, should I set a new serial in order to not confl=
ict
> 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 fro=
m
> the originalm root-ca and the new one ?
>
> thanks .
> ______________________________________________________________________
> OpenSSL Project =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.openssl.=
org
> User Support Mailing List =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0opens...@openssl.org
> Automated List Manager =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 majo...@openssl.org
Peter Sylvester
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
jehan procaccia
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<jehan.p...@it-sudparis.eu> wrote:
>
>> jehan procaccia a écrit :
>>
>>> I finally found it !
>>>
>>> [procacci@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(00000003)
>>> 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 .
jehan procaccia
> 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.
>
"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