SHA-1 OCSP responder certificates

[Ben Wilson]

On 4-Sept-2017 we were advised through our designated revocation email address that we needed to examine the certificates listed below, which were issued to several OCSP responders using SHA1, and that we should report these to this list. Thus the reason for this post.



We immediately contacted the operators of the issuing CAs and requested that they replace their OCSP responder certificates with ones signed with SHA2, and most have done so. However, in drafting this post I reviewed the Baseline Requirements, section 7.1.3, which I think is ambiguous and allows SHA1 OCSP Responder Certificates in some situations. It says, “Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017. This Section 7.1.3 does not apply to Root CA or CA cross certificates. CAs MAY continue to use their existing SHA-1 Root Certificates.” (The EKU in these certificates indicates they are to be used for “OCSP Signing” and not “Server Authentication”, so it is not a matter of SSL/TLS server certificate misissuance.) Most of the CAs served by these OCSP responders are legacy CAs, which are in the process of being retired. For example, the Intesa Sanpaolo CA Servizi Esterni only has 14 active certificates, with the last one expiring mid-December 2017.



DC=com, DC=sanpaoloimi, DC=corp, CN=Intesa Sanpaolo CA Servizi Esterni

https://crt.sh/?id=201260285 <https://crt.sh/?id=201260285&opt=cablint> &opt=cablint SHA-1 (EKU: OCSP Signing)



C=NL, L=Amsterdam, O=Verizon Enterprise Solutions, OU=Cybertrust, CN=Verizon Public SureServer CA G14-SHA1

https://crt.sh/?id=201260309 <https://crt.sh/?id=201260309&opt=cablint> &opt=cablint SHA-1 (EKU: OCSP Signing)



C=NL, L=Amsterdam, O=Verizon Enterprise Solutions, OU=Cybertrust, CN=Verizon Public SureCodeSign CA G14-SHA1

https://crt.sh/?id=201260337 <https://crt.sh/?id=201260337&opt=cablint> &opt=cablint SHA-1 (EKU: OCSP Signing)



C=NL, L=Amsterdam, O=Verizon Enterprise Solutions, OU=Cybertrust, CN=Verizon Akamai SureServer CA G14-SHA1

https://crt.sh/?id=201260459 <https://crt.sh/?id=201260459&opt=cablint> &opt=cablint SHA-1 (EKU: OCSP Signing)



CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT

https://crt.sh/?id=201260500 <https://crt.sh/?id=201260500&opt=cablint> &opt=cablint SHA-1 (EKU: OCSP Signing)



C=PT, O=SCEE - Sistema de Certificação Electrónica do Estado, OU=ECEstado, CN=Cartão de Cidadão 002

https://crt.sh/?id=201260501 <https://crt.sh/?id=201260501&opt=cablint> &opt=cablint SHA-1 (EKU: OCSP Signing)



O="Cybertrust, Inc", CN=Cybertrust Global Root

https://crt.sh/?id=201186966 <https://crt.sh/?id=201186966&opt=cablint> &opt=cablint pathLenConstraint with CA:FALSE (EKU: OCSP Signing)



We look forward to your response and comments.



Ben Wilson

DigiCert VP of Compliance

[Gervase Markham]

On 07/09/17 00:41, Ben Wilson wrote:
> We immediately contacted the operators of the issuing CAs and
> requested that they replace their OCSP responder certificates with
> ones signed with SHA2, and most have done so. However, in drafting
> this post I reviewed the Baseline Requirements, section 7.1.3, which
> I think is ambiguous and allows SHA1 OCSP Responder Certificates in
> some situations. It says, “Effective 1 January 2016, CAs MUST NOT
> issue any new Subscriber certificates or Subordinate CA certificates
> using the SHA-1 hash algorithm. CAs MAY continue to sign certificates
> to verify OCSP responses using SHA1 until 1 January 2017.

I interpret that as saying that if your OCSP responder's signing
certificate was created before 1 January 2017, and was signed using
SHA-1, you can keep using it until it expires.

However, note that Mozilla policy has some additional requirements in
this area, notably that SHA-1 certs used to sign OCSP responses must be
technically constrained to be only used for OCSP signing.

Gerv