Hello Thomas, > thanks for the fast reply! We always try to be fast ;D > >> OpenXPKI supports the concept of "PKI Realms". A Realm in our >> terminology should be considered a logical CA, for example a CA >> that issues certificates for server systems (web server, mail >> server etc) only. Within a realm, any > number of Issuing CAs can >> be configured, but the idea here is that these Issuing CAs are all >> responsible for issuing certificates for this dedicated purpose. >> The "any number of CAs" part in a Realm is there in order to allow >> for seamless rollover of expiring Issuing CAs - you can configure a >> new Issuing CA that automatically takes over the work of the >> previous CA without any noticeable user impact (if you distribute >> the Root CAs properly, that is). > > Ok. I understood that the realms are for modelling the hirarchy > levels and the multiple issuing CAs are only for a seamless rollover. > How would that rollover work? As far as I understood only one issuing > CA can be active at a time since I can only configure one issuing ca > in crypto.yaml under the key certsign.
The short story: Just dont care about the details. Start with your current issuing ca as it is configured with the sample setup. If your ca approaches the end of usability, create a new issuing certificate and import it into the realm. As soon as the "notbefore" date of the new certifiacte is reached, OpenXPKI starts to use it. The longer story: The name "ca-one-signer" given in the crypto.yaml is not the name of ONE token but of the token group. Internally, the system treates each issuing ca as a member of the signer group, where each one has a so called generation identifier attached. If you run "openxpkiadm alias --realm ca-one" you will see something like certsign (ca-one-signer): Alias : ca-one-signer-1 Identifier: o9vUk4acB6GjJ3M-NlcdHuXAG3w NotBefore : 2013-10-12 19:54:40 NotAfter : 2016-10-11 19:54:40 The "-1" is the generation and if you import a second signer certificate into the "ca-one-signer" group, you will get a token namen "ca-one-signer-2". The reference to the key blob given in crypto.yaml is key: /etc/openxpki/ssl/ca-one/[% ALIAS %].pem where the alias is the complete token alias, group + generation. So you really just put your next generation ca (if necessary including a new root chain) into the configuration and OpenXPKI cares about anything else. To put some more fun into it - you can override the notbefore/notafter dates of the certificate to administrativley set an exact point in time when the rollover should happen without the need to fiddle with the dates of the ca certificate. If you want more insight, call in for a beer ;) Oliver -- Protect your environment - close windows and adopt a penguin!
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform
_______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
