Hi,

> As am trying to enable the CA rollover on the openxpki.
> 1)a)Mainly openxpki has the SCEP feature and am trying to generate the 
> certificates like
> Ca-one –scep-1.crt ,ca-one-vault-1.crt ,ca-root-1.crt ,ca-one-signer-1.crt
> Generally in these ca-root-1.crt is the root CA certificate and
> Ca-one-signer-1.crt is the intermediate certificate
> While am attempting to invoke getca command I will get three certificates like
> Ca-one –scep-1.crt 0 cert
> ca-root-1.crt , 1 cert
> ca-one-signer-1.crt 2 cert

Correct, when calling getca on an OpenXPKI SCEP server you will always get the 
SCEP RA cert first and all certificates required to complete certificate chains 
on the client side.

> b)After that I have been generating the certificates like
> Ca-one –scep-2.crt ,ca-one-vault-2.crt ,ca-root-2.crt ,ca-one-signer-2.crt
> Generally in these ca-root-2.crt is the root CA certificate and
> Ca-one-signer-2.crt is the intermediate certificate
> And am updating the certs not before and not after the valid time like 
> Openxpkiadm alias –update –realm ca-one –alias ca-one-scep-2 –notbefore “ 
> 2018-01-01:00:00:00”
> While we are attempting to invoke GETNEXTCA command we will get only Root CA 
> certificate (means am getting only one certificate,am not getting full 
> trusted chain certificates).

When preparing for a CA rollover the first step is usually to import the new 
Root Certificate and configure the new Root in the Issuing CA realm. You seem 
to have done this correctly, as you are getting the new Root CA when calling 
GETNEXTCA. This is the point of the GETNEXTCA command: it allows you to 
distribute the upcoming Root CA to the clients long before you perform the 
actual rollover. The client’s responsibility is to take the new Root returned 
and configure it as trusted.

OpenXPKI only delivers the new Root CA when calling GETNEXTCA, as this is the 
only certificate that is actually required by the client to prepare for the 
rollover. Once the client has accepted the Root CA cert delivered by GETNEXTCA 
in addition to the old Root CA cert it will be prepared to deal with any 
combination of Issuing CA cert (issued below old or new Root) and SCEP RA cert 
(issued below old or new Issuing CA). All these cases can then be properly 
handled by using the certificates which are returned in the GETCA command which 
returns the CA chain as well as the currently used SCEP RA certificate.

For actually performing the rollover you must perform the rollover of the 
Issuing (Signer) certificate. From the command above it looks like you have 
tried to do it with the the SCEP certificate.

The correct way to prepare a rollover is:

1. Import new Root Certificate in OpenXPKI and configure the new Root 
Certificate in the CA realm
2. Wait for an arbitrary amount of time while your organization adopts the new 
Root Cert, possibly supported by GETNEXTCA which will deliver the new Root Cert
3. Once you are ready for the rollover: import the new Issuing CA Certificate 
into the realm. Once a suitable Issuing CA cert is available, OpenXPKI will 
automatically roll over when issuing new certs. CRLs will still be created for 
all Issuing CAs still valid

Optional: you can roll over the SCEP RA cert at the same time with the Issuing 
CA cert, but you don’t have to. If the old SCEP cert is still valid, it will 
continue to work for the SCEP server. However, there are SCEP clients which 
don’t properly implement PKIX best practices, so it might be advisable to roll 
over the SCEP RA cert to one issued by the new hierarchy immediately after the 
new Issuing CA cert is active.

As I mentioned, the rollover happens automatically once a suitable Issuing CA 
cert is found, and OpenXPKi is quite clever about this. A rollover can either 
be scheduled to happen fully automatically at a set point in time, of it can be 
manually triggered.

For manual trigger, the easiest way is to delay installation of the new Issuing 
CA cert in the realm until the point in time when you want it to happen. An 
alternative is to import the new Issuing CA prior to the rollover, but specify 
an „administrative notbefore“ date for the Issuing CA certificate which is far 
in the future. The rollover is then triggered by simply resetting this 
adminstrative notbefore date.

For automatic (time based) trigger you have two options:
1. Issue the upcoming Issuing CA certificates with a NotBefore date in the 
future, set to the date when the rollover is scheduled. Once you import the new 
Issuing CA certificate it will not be considered as a suitable Issuing CA 
certificates (because it is not yet valid). Once the NotBefore date passes, it 
will automatically be used for issuing new end entity certificates.
2. When importing the Issuing CA certifiate you can set an „administrative“ 
NotBefore date which overrides the NotBefore date in the certificate. This way 
you can specify an arbitrary date within the validity of the Issuing CA 
certificate when the rollover shall happen.


Cheers

Martin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Reply via email to