PKI Consortium blog

One Year Certs
July 9, 2020 by Patrick Nohe (GlobalSign) Apple CA/Browser Forum DV Google Identity Microsoft PKI Policy Root Program SHA1 SHA2 SSL/TLS
Starting on September 1st, SSL/TLS certificates cannot be issued for longer than 13 months (397 days). This change was first announced by Apple at the CA/Browser Forum Spring Face-to-Face event in Bratislava back in March.

2015 – Looking Back, Moving Forward
January 6, 2015 by Bruce Morton (Entrust) Apple Attack CA/Browser Forum CAA Chrome Code Signing EV Firefox Forward Secrecy Google IETF Malware Microsoft MITM Mozilla OpenSSL PKI Policy RSA SHA1 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3 Vulnerability

Looking Back at 2014

End of 1024-Bit Security

In 2014, the SSL industry moved to issuing a minimum security of 2048-bit RSA certificates. Keys smaller than 2048 are no longer allowed in server certificates. In addition, Microsoft and Mozilla started to remove 1024-bit roots from their certificate stores. Hopefully, the key size change will support users through to 2030.

Google Plans to Deprecate SHA-1 Certificates – Updated
September 24, 2014 by CA Security Council Announcement Attack CASC Chrome Code Signing Google Microsoft Policy SHA1 SSL/TLS

UPDATED September 23, 2014: The following blog post has been updated with action taken in recent weeks, as well as to reflect helpful user comments left on our August 28 blog post on this topic.

On August 19, Google announced a new policy that accelerates the deprecation of SHA-1 certificates, potentially causing websites using SHA-1 certificates to display warnings in the near future. While keeping with an earlier Microsoft announcement to accept SHA-1 certificates with an expiration date before Jan. 1, 2017, the Google policy will provide new “untrusted” warnings in regards to such certificates as early as this November.

2014 – Looking Back, Moving Forward
January 6, 2014 by Bruce Morton (Entrust) Attack BEAST CA/Browser Forum CAA Code Signing ECC Encryption Forward Secrecy HSTS ICANN IETF Microsoft MITM Mozilla PKI Policy RC4 RSA SHA1 SSL/TLS TLS 1.2

Looking Back at 2013

Protocol Attacks

The year started with a couple of SSL/TLS protocol attacks: Lucky Thirteen and RC4 attack. Lucky Thirteen allows the decryption of sensitive information, such as passwords and cookies, when using the CBC-mode cipher suite. Lucky Thirteen can be mitigated by implementing software patches or preferring the cipher suite RC4.

SHA-1 Deprecation, On to SHA-2
December 16, 2013 by Bruce Morton (Entrust) Code Signing Microsoft PKI Policy SHA1 SSL/TLS

We have previously reviewed implementation of SHA-2, but with Bruce Schneier stating the need to migrate away from SHA-1 and the SHA-1 deprecation policy from Microsoft, the industry must make more progress in 2014.

Web server administrators will have to make plans to move from SSL and code signing certificates signed with the SHA-1 hashing algorithm to certificates signed with SHA-2. This is the result of the new Microsoft Root Certificate Policy where Microsoft deprecates SHA-1 and imposes the following requirements:

Encryption Still Works – It’s About How You Implement It
September 13, 2013 by Ben Wilson ECC Encryption Malware RSA SHA1 SHA2 SSL/TLS TLS 1.1 Vulnerability

The September 5th joint article by the New York Times and Guardian newspapers on NSA’s and GCHQ’s efforts to circumvent encryption implementation have left many people speculating on the security of the data they are transmitting over the Internet. Hopefully, this blog post will provide some guidance and help understand SSL in light of these recent articles. Importantly, the articles point out that the primary means of attacking SSL/TLS do not exploit a vulnerability in the protocol itself but instead aim to exploit poor implementations of the protocol, insecure servers, and weak cryptography.

Public Key Pinning
August 28, 2013 by Bruce Morton (Entrust) Android Chrome Google IETF Mis-issued SHA1 SSL/TLS

The current browser-certification authority (CA) trust model allows a website owner to obtain its SSL certificate from any one of a number of CAs. That flexibility also means that a certificate mis-issued by a CA other than the authorized CA chosen by the website owner, would also be accepted as trustworthy by browsers.

This problem was displayed most dramatically by the DigiNotar attack in 2011 and in a mistaken CA certificate issued by TURKTRUST in 2012. In these cases, certificates were issued to domains that were not approved by the domain owner. Fortunately, the problem was detected in both cases by public key pinning, which Google implemented in Chrome.