Dear HARICA subscribers,
We recently became aware that some elements of our Certification Policy/Certificate Practice Statement related to Certificate Revocation have not been so clearly communicated to our Subscribers. This article attempts to describe some recommended practices for Subscribers, and some bad practices (to be avoided) in order to improve the overall security of the use of Publicly-Trusted Digital Certificates for the benefit of Relying Parties worldwide.
Based on 4.9.1 Circumstances for revocation of HARICA’s Certificate Policy and Certification Practices Statement, by the time HARICA detects or receives a notification for a problematic certificate, must immediately inform the Subscriber. Under certain conditions, HARICA SHALL revoke a Subscriber Certificate within twenty four (24) hours to an extended five (5) days period, depending on the certificate type (TLS, S/MIME, eSignature, etc.) and the scale of the threat. For example, Certificates with incorrect values in their subject have a grace period of five (5) days but for Certificates that suffered a Key Compromise their revocation will be within twenty four (24) hours.
Also, under certain conditions, HARICA SHALL revoke a Subordinate CA Certificate within seven (7) days in case of reasons described in HARICA’s Certificate Policy.
A subset of these requirements are standardized Globally via the CA/Browser Forum’s Baseline Requirements, and all CAs issuing Publicly-Trusted TLS Certificates worldwide must adhere to these rules for Certificates in scope of this standard.
This means that ALL Subscribers that control HARICA Publicly-Trusted digital certificates must be prepared to ACT in an agile manner in order to replace existing Certificates within the above timeframes, once notified by HARICA.
Currently there is no requirement for Subscribers to inform or explain to HARICA in detail how they plan to use HARICA’s Certificates for Relying Parties to use. However, Subscribers must keep in mind the revocation requirements that they have agreed to via the Subscriber Agreement, and adjust their implementations/projects/solutions in such a way that their Certificates can be replaced in a timely manner within the specific timeframes, if needed.
Implementations that are considered problematic
HARICA contacted a number of Subscribers and organizations that developed solutions based on HARICA’s Certificates, and received some useful feedback. Although it is not our intention to criticise or comment about the design decisions of these use cases, it was obvious that the Subscribers/implementers’ intentions were to improve security (and in one sense this was accomplished by limiting the number of “allowed” Certificates) but at the same time there were unintended consequences (for example the difficulty in replacing certificates and adapting timely to industry or CA policy changes).
Certificate-based solutions that explicitly rely on information that is included in Issuing CA Certificate(s) is one of the popular reasons that cause difficulty for Subscribers to replace their Certificates. This practice is known as “certificate pinning”. Whether for TLS Client or Server Authentication, when an application “expects” some Certificates to be issued by specific Issuing CA Certificates, it is considered problematic. HARICA and other Certification Authorities are at liberty of introducing new Issuing CA Certificates and use those for issuing Subscriber Certificates, without prior alerting or contacting Subscribers or Relying Parties. Applications and solutions that are “pinned” on specific CA Certificates are likely to “break”, and will most probably need to be manually updated, therefore it is recommended that “certificate pinning” is avoided. Applications and solutions can always use information of the Subject Distinguished Name of end-entity Certificates to limit the Authentication scope.
Here is a list of applications/solutions that were reported to use certificate pinning:
- user authentication for VPN services
- user authentication on Web services
- in Android apps
- validation of digital signatures of specific organization(s)
There are also authentication schemes that rely on digital Certificates for authentication and signatures, mainly for server-to-server communication. The SAML2 authentication scheme is very popular especially in the Academic and Research sector (eduGAIN, InCommon Federation), where Identity Providers and Service Providers use Certificates to sign their Metadata and SAML2 assertions. Administrators of such services must be aware that these certificates don’t have to be Publicly-Trusted, and in fact they should either be self-signed or issued from a private PKI.
Be proactive and prepare for speedy Certificate Replacement
There are several reasons that Subscribers of Publicly Trusted Certificate need to be ready to quickly replace Certificates. Regardless of the use cases, there are always inherent risks in the technology used in Digital Certificates/Signatures. Policy requirements also change from time-to-time. For example, some existing methods for Domain and Identity Validation may become forbidden or deprecated because in the light of new evidence they are considered insecure. If these insecure methods were used for the issuance of certificates, it is possible that these certificates need to be tracked down and revoked.
Crypto and Policy agility are reasons that require CAs such as HARICA, Subscribers and Relying Parties to be in a position to adapt quickly to changes.
HARICA suggests the following good practices to TLS certificate subscribers:
- subscribers can use ACME-based solutions for automatic certificate issuance/renewal. HARICA has an ACME beta solution for selected pre-validated Organizations to automatically issue TLS Certificates. This solution is planned to be offered to all Subscribers.
- subscribers using TLS certificates in services/devices that implement old deprecated software/protocols (e.g. TLS 1.0 or 1.1 for IP camera software), it is recommended to use proxies which provide secure TLS connection termination using the latest protocol versions that also support ACME.
HARICA is prepared to respond to a demand for quick certificate replacement for non-TLS Certificates:
- For S/MIME, Advanced eSignature/Seal and Code Signing (not EV), HARICA can re-key a certificate to issue an entirely new certificate, using some or all information submitted for an existing certificate and using a newly generated Key Pair.
- For EV Code Signing and Qualified eSignature/Seal Certificates, in case the crypto-device or private key IS NOT compromised, HARICA can
- use the same Key-Pair and issue an entirely new certificate, using some or all information submitted for an existing certificate or
- generate a new Key Pair and re-key an existing certificate
- use an existing Key Pair that was generated during the provisioning process of a crypto-token device and issue a new certificate.
- For Remote eSignature/Seal Certificate Subscribers, HARICA can use re-keying to issue an entirely new certificate, using some or all information submitted for an existing certificate and using a newly generated Key Pair.
Related Articles
