- How your CA first became aware of the problem
After the following serial number issue was reported against EJBCA
Entrust Datacard performed an investigation into its use of EJBCA and found that only the offline AffirmTrust root CAs utilized EJBCA with the indicated 64bit configuration issue. This resulted in AffirmTrust issuing CAs’ serial numbers not meeting the BR 7.1, 64-bit requirements.
- A timeline of the actions your CA took in response
March 13, 2019: News about the EJBCA serial number issue was reported and confirmed
March 14, 2019: Our internal investigation started
March 18, 2019: Our operations team confirmed that Seven issuing CA/intermediate certificates from our AffirmTrust brand were impacted by the reported problem and only included 63-bit serial numbers. They also found one end entity certificate with a 63-bit serial number that is still active.
- Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem
We will increase our serial number byte length to 128 bits by March 22nd using a re-sign operation to ensure that our intermediate certificates comply with the minimum 64-bit serial number length.
- A summary of the problematic certificates
Seven issuing CA/Intermediate certificates were impacted, as EJBCA was used to cross-certify these certificates with an AffirmTrust root CA.
We also discovered that there is one active end entity certificate issued by our AffirmTrust CAs. Prior to our acquisition of AffirmTrust, EJBCA was used for both the roots and the issuing CAs. The AffirmTrust issuing CA software was changed from EJBCA to the Entrust Authority PKI on 14 January 2017 and no end-entity certificates issued after this date are impacted by the EJBCA serial number bug.
- The complete certificate data for the problematic certificates
Production Intermediate Certificates:
Non-production Intermediate Certificates (no active end-entity certificates) :
End Entity Certificate that was impacted:
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The EJBCA issue that impacted certificate serial numbers was first reported last week. Our internal certificate linting tools failed to identify the issue since only end entity certificates are checked and none of the end entity certificates have the issue.
- List of steps your CA is taking to resolve the situation
Entrust Datacard will re-sign the issuing CA keys and increase the serial number size to 128 bits by March 22.
We have decided that we will not revoke the issuing CA/intermediate certificates impacted by the EJBCA 63 bit serial number issue at this time. The strain that this will put on our customers to replace their intermediate certificates drastically outweighs the potential risk we see in allowing these intermediate certificates to remain valid. After an in-depth assessment, our security team believes that there are no practical security issues or exploits in this scenario, keeping in mind that all of our issuing CAs are signed with SHA-2, that they are isolated, and that our roots are kept in an offline state.
The CA/Browser Forum Baseline Requirements Version 1.6.4 state:
Effective September 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.
This language was introduced in Ballot 164, replacing the original requirement:
CAs SHOULD generate non‐sequential Certificate serial numbers that exhibit at least 20 bits of entropy.
The statement of intent in the ballot describes resistance to attacks on hash functions, especially to hash function collision attacks, as the rationale for this change:
As demonstrated in https://events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf, hash collisions can allow an attacker to forge a signature on the certificate of their choosing. The birthday paradox means that, in the absence of random bits, the security level of a hash function is half what it should be. Adding random bits to issued certificates mitigates collision attacks and means that an attacker must be capable of a much harder preimage attack. For a long time the Baseline Requirements have encouraged adding random bits to the serial number of a certificate, and it is now common practice. This ballot makes that best practice required, which will make the Web PKI much more robust against all future weaknesses in hash functions. Additionally, it replaces “entropy” with “CSPRNG” to make the requirement clearer and easier to audit, and clarifies that the serial number must be positive.
As indicated above, the AffirmTrust offline root certification authorities have issued currently valid cross-certificates with serial numbers containing less than 64 bits coming from a CSPRNG. These root certification authorities do not issue end-user certificates but do issue cross-certificates for the AffirmTrust issuing CAs. The issuance of the implicated cross-certificates was not in practice vulnerable to hash collision attacks for the following reasons:
• The certificate signature algorithm uses the SHA-256 hash algorithm, which currently has 128-bit security strength against collision attacks.
• The input to the cross-certification process is generated within an Entrust Datacard isolated network zone and is thus under Entrust Datacard's control.
• The affected root certification authorities are offline roots and are housed in an isolated network zone. As such, they are used only to generate a small number of certificates.
• The affected root certification authorities are shut down except during issuance of cross-certificates and CRLs.
Thus, although including more CSPRNG output in the certificate serial numbers would be preferable, there was no practical attack known at the time the certificates were issued, and revoking them is therefore unnecessary from a security perspective. In addition, if the cross-certificates were revoked, all customers with certificates issued by the issuing CAs would need to deploy new cross-certificates, posing an unnecessary burden on those customers.
Entrust Datacard is working to revoke the single end entity certificate that was impacted before March 22.
Entrust Datacard will also revoke the non-production intermediate certificate with no active end-entity certificates (https://crt.sh/?id=98714371) before March 22.