swedenconnect / ca-cmc Goto Github PK

Current CMC client need information about the CA in order to perform some operations:

• Get certificate: Requires the CA certificate of the CA
• Revoke certificate: Requires the CA certificate of the CA
• Get certificate model builder: Requires the CA certificate, The CA issuing algorithm, CRL DP:s and OCSP responder URL

This information is currently obtained from the CA by sending a custom Admin request to the CA. A problem with this request is that this also returns information that is not needed, but which may consume lots of work by the CA, such as returning the number of issued certificates and the number of issued and non-revoked certificates.

To mitigate this, the current implementation cache CA information and has a configurable time interval deciding how old this CA information may be before re-cache.

This is still not ideal in high volume scenarios, where an unlucky user is made waiting for the CA to answer the request and where this may lead to issues that are hard to resolve because it only occurs on re-cache.

In order to maintain backwards compatibility, but still the best functionality for the future, the following re-design is proposed:

• Keep current CA information request using CMC intact (for backwards compatibility)
• Add a new "Static CA information request" that only returns static information about the CA that 1) can be cached for a long time and 2) is easy to respond to by the CA
• Make and abstract implementation of CMCApi (AbstractCMCApi) and 2 implementations
  • The current CMCAPi that will use the new static CA information request
  • A new PreConfiguredCMCApi that will use pre configured values instead of doing any request at all to the CA for CA information.

The rationale for the PreConfiguredCMCApi is to allow the sign service to issue certificate without having to do any custom CMC requests at all, making it easier to integrate the sign service with any CA supporting standard CMC.

The underlying CMC implementation fully supports PKCS#10 request format, but the AbstractCMCClient has limitations resulting in

• CRMF request format is always used
• The profile requested has a fixed value of "crmf"

This should be updated to allow creation of certificate issuing requests based on PKCS#10 request format, and should allow the profile parameter (regInfo) to be set freely as byte[] array.

1.9.3 has reported vulnerabilities

Exception handling should be fixed to ensure that the CMC client does not provide an unchecked exception unless the error is caused by internal misconfiguration or a programming error in its use.

All errors caused by a bad or unserviceable request should result in a checked exception.

Since the AbstractCertificateModelBuilder has been updated we need to update CMCCertificateModelBuilder

Enhance the AbstractCMCClient class to properly check and log if valid CMC data could not be obtained.

As of now, if fails first at the attempt to parse time data and the log suggests problem with time data instead of relevant information about the underlying problem.