Hi Ralf, > Hi, i´m using OpenXPKI Community Edition v3.28.2 and I am currently testing > the issuing certificate rollover. > For this purpose, ca-signer-1 and ca-signer-2 exist in the OpenXPKI. The > queries via SCEP and EST lead to different results. > The query via EST for CA certificates returns the last one (ca-signer-2), > whereas the query via SCEP returns the first one (ca-signer-1). > In my opinion Openxpki should return the same result in both cases, > preferably the last issuing certificate, as this will be "the new > certificate" after the rollover. > It would also be dangerous using in a certificate request "the old > certificate" as an anchor for the trust chain shortly before it expires.
Well, it is not that easy. First, for EST the underlying RFC 7030 https://www.rfc-editor.org/rfc/rfc7030#section-4.1.3 specifically requests > 4.1.3. CA Certificates Response > > ... > > The EST server MUST include the current root CA certificate in the > response. The EST server MUST include any additional certificates > the client would need to build a chain from an EST CA-issued > certificate to the current EST CA TA. For example, if the EST CA is > a subordinate CA, then all the appropriate subordinate CA > certificates necessary to build a chain to the root EST CA are > included in the response. This is also the default behavior implemented by OpenXPKI (see OpenXPKI::Server::Workflow::Activity::EST::CACerts) and matches the behavior you observed. Note that EST suggests to prepare the CA rollover case via Root CA Cross-Signing and delivering the glue certificates via the same channel: > The EST server SHOULD include the three "Root CA Key Update" > certificates OldWithOld, OldWithNew, and NewWithOld in the response > chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST > client MUST be able to handle these certificates in the response. > The EST CA's most recent self-signed certificate (e.g., NewWithNew > certificate) is self-signed and has the latest NotAfter date. If the > EST server does not include these in the response, then after the > current EST CA certificate expires, the EST clients will need to be > reinitialized with the PKI using the Bootstrap Distribution of CA > certificates (Section 4.1.1) method, which involves user interaction. This operation mode is supported by OpenXPKI Enterprise Edition, but note that it also requires creation of the Root CA glue certificates which is out of scope for OpenXPKI (but supported by our clca Enterprise Edition which we recommend for running a professionally managed Root CA). For SCEP, the standard is not that specific. RFC 8894 https://www.rfc-editor.org/rfc/rfc8894.html#section-2.2 requires > 2.2. CA Certificate Distribution ... > If an intermediate CA is in use, a certificates-only CMS SignedData message > with a certificate chain consisting of all CA certificates is returned. > Otherwise, the CA certificate itself is returned. > The CA certificate MAY be provided out of band to the client. Alternatively, > the CA certificate fingerprint MAY be used to authenticate a CA certificate > distributed by the GetCACert response (Section 4.2) or via HTTP > certificate-store access [RFC4387]. The fingerprint is created by calculating > a SHA-256 hash over the whole CA certificate. (For legacy reasons, a SHA-1 > hash may be used by some implementations.) > After the client gets the CA certificate, it SHOULD authenticate it in some > manner unless this is deemed unnecessary, for example, because the device is > being provisioned inside a trusted environment. For example, the client could > compare the certificate's fingerprint with locally configured, out-of-band > distributed, identifying information, or by some equivalent means such as a > direct comparison with a locally stored copy of the certificate. > Intermediate CA certificates, if any, are signed by a higher-level CA, so > there is no need to authenticate them against the out-of-band data. Since > intermediate CA certificates are rolled over more frequently than long-lived > top-level CA certificates, clients MUST verify intermediate-level CA > certificates before use during protocol exchanges in case the intermediate CA > certificate has expired or otherwise been invalidated. Note that this section is not as specific as the EST counterpart. It merely suggests that the GetCACert response shall include the necessary CA certificates an end entity might need to properly build certificate chains. There are many possible intricacies associated with this, many of which are not explicitly covered by this RFC. Suffice to say, we have encountered several pathological situations in our projects which required us to specifically craft the GetCACert response to cater for requirements resulting from end entity implementation restrictions and PKI architecture constraints. One prominent and quite common case is that the SCEP RA certificate was not signed by the current Issuing CA CA which can make sense but requires GetCACert to deliver CA Certificates from two different CA Chains: the chain for the SCEP RA certificate (which the end entity needs to verify the validity of the SCEP server) and the chain for the current Issuer CA (which the end entity will need to compose the certificate chain for the newly issued certificate). The latter is very likely the situation you are observing. I suspect that your SCEP RA certificate was issued by the previous Issuing CA, hence the results of the GetCACert command contains the necessary chain certificates for both generations. For the more obscure cases (and we have seen many of those), OpenXPKI allows to prepare a specific set of CA Certificates to deliver to the SCEP client. We introduced this in order to address the number of cases in which incompliant or wonky SCEP implementations, of which there are many out there. SCEP handles the CA rollover via the GetNextCACert operation: > When a CA certificate expires, certificates that have been signed by it may > no longer be regarded as valid. CA key rollover provides a mechanism by which > the CA can distribute a new CA certificate that will be valid in the future > once the current certificate has expired. This is done via the GetNextCACert > message (Section 4.7). > This is supported by OpenXPKI out of the box. BTW, feel free to contact White Rabbit Security off-list if you have specific IoT PKI needs you would like to address. We have lots of experience with bringing such project up and running properly and quickly, and making sure that the resulting architecture is fit for potentially indefinite operation. Cheers Martin _______________________________________________ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
