Hey Martin,
thanks for the fast reply!
> 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.
> For the Root CA consider https://github.com/openxpki/clca CLCA - it can
be installed on a bootable medium and supports secret sharing of the Root
CA private key (in software) as well as nCipher HSMs.
Thanks for the tip. I will consider it.
2014-04-22 14:26 GMT+02:00 Martin Bartosch <[email protected]>:
> Hi Thomas,
>
> > I'm currently starting to create a PKI and want to have one root ca
> (level 0) and several intermediate certificates (level 1) below the CA.
> Currently the sample setup of openxpki creates one root CA and one
> intermediate CA (openxpki calls it *signer*) which actually signs all the
> certificates you create.
>
> this is a very good idea and recommended practice.
>
> For any PKI setup that is not solely for testing only, you should always
> have a distinct Root CA (offline) and one or more subordinate issuing CAs.
> OpenXPKI is fully compliant with this approach and can implement any
> number of CA hierarchy levels.
>
> > Since we have a lot of subjects (different vpns, ssl certificates
> (webserver and user)) to cover I thought about creating an intermediate CA
> for each subject to have it separated.
> >
> > The question now is: How could I solve this with Openxpki?
>
> 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).
>
> One of the most important features of OpenXPKI is this automatic rollover.
> Used properly, it allows for totally continuous PKI operation without
> admins sweating about what happens if the CA validity runs out...
>
> Within a PKI Realm you can configure an arbitrary number of certificate
> profiles. For the "Server CA Realm" you might want to have one that is for
> TLS/Web Servers, one for TLS Clients, one for systems acting in both roles,
> one for SCEP clients, you get the idea.
>
> Our recommendation is to set up Realms for high level subject separation,
> e. g. in our reference implementation we have one realm for Servers, one
> strictly only for Humans/Users (Smartcard, Email-Gateway), one for devices
> (anything not a person and not in a datacenter) and so on. Then distinguish
> certificate purposes by usage of certificate profiles within the realms.
>
> Our documentation contains some details about the CA realm configuration:
>
> > Currently I can't see an option for using multiple signer certs within
> one realm (At first I thought one realm=one CA). The only way I can think
> of to achieve this is to create one realm for each intermediate CA and
> create for everey realm one token which links to the actual one and only
> root ca token imported first.
> >
> > Is this a way to go or maybe the intended way of handling multiple
> intermediate CAs?
>
> My recommendation is to have one Root and derive all the intermediate CAs
> from this Root. Plan for Root CA rollover, as well as for Issuing CA
> rollover if you want to be able to run the CA instance for a long time
> without interruption. (Consider professional consulting, not *necessarily*
> from us ;-) - but from someone with a clue if you are not entirely sure how
> to achieve this.)
>
> For the Root CA consider https://github.com/openxpki/clca CLCA - it can
> be installed on a bootable medium and supports secret sharing of the Root
> CA private key (in software) as well as nCipher HSMs.
>
> Cheers,
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
