Hi Massimiliano
Massimiliano Pala wrote:
It is very simple indeed, just edit the config file and, in the dbms
section
list all the 9 CAs sections, like this:
0.ca = @first_ca
1.ca = @second_ca
2.ca = @third_ca
...
8.ca = @eighth_ca
---
Then add the listed CAs (in the config file) by adding:
---
[ first_ca ]
crl_url = file:///crls/crl_01.pem
ca_url = file:///certs/1st_cacert.pem
[ second_ca ]
crl_url = file:///crls/crl_01.pem
ca_url = file:///certs/1st_cacert.pem
[ third_ca ]
crl_url = file:///crls/crl_01.pem
ca_url = file:///certs/1st_cacert.pem
...
[ eighth_ca ]
crl_url = file:///crls/crl_01.pem
ca_url = file:///certs/1st_cacert.pem
---
Obviously some of the CAs data can be downloaded from LDAP and other from
file, it depends on your local configuration. Nevertheless it is very
simple.
Let me know if you have problems and/or questions.
OK. So the responder can figure out which CA (and CRL) from either the
issuerNameHash or issuerKeyHash that the client should put in the request.
The only question I have now is about the signing of the response. Out
of the 3 options given in the RFC2560 the direct siging by the CA that
issued the cert seems out of contention. The CA Designated Responder
seems out of contention aswell since it has to be signed directly by the
CA that issued the cert. That leaves the "Trusted Responder whose public
key is trusted by the requester". This means that the client application
will ignores the AIA attribute.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Openca-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openca-users
