PKI Consortium blog

What is Certification Authority Authorization?
September 25, 2013 by Rick Andrews CAA IETF Policy SSL/TLS

DNS Certification Authority Authorization (CAA), defined in IETF draft RFC 6844, is designed to allow a DNS domain name holder (a website owner) to specify the certificate signing certificate(s) authorized to issue certificates for that domain or website. Usually, the certificate signing certificate will belong to the Certification Authority (CA) that issues SSL certificates to you. It’s a way for you to indicate which CA or CAs you want to issue certificates for your domains. Using CAA could reduce the risk of unintended certificate mis-issuance, either by malicious actors or by honest mistake.

Getting the Most Out of SSL Part 3: Optimization
July 29, 2013 by Rick Andrews, Ryan Hurst MITM Mixed Content SSL/TLS

To get the most out of SSL/TLS, you need to do a bit more than just configure your web server with an SSL certificate. The information below will help you optimize your website’s use of SSL. Making the changes suggested below will also help move your site towards “Always On SSL” (https://otalliance.org/resources/AOSSL/index.html), a best practice in which you serve the entire contents of your website over SSL/TLS.

Changes to the content of your website

Some HTML tags can include attributes that are links or paths to other pages on your site. These paths can be absolute (explicitly referencing a protocol and domain name, like href=”http://foo.example.com/index.htm” or src=”https://foo.example.com/script.js”) or relative (like href=”/index.htm” or src=”/script.js”).

Recap of NIST’s Workshop on Improving Trust in the Online Marketplace
April 17, 2013 by Rick Andrews CA/Browser Forum CASC NIST Revocation SSL/TLS

On April 10 and 11, NIST held a workshop in Maryland to bring together many parties (industry, research and academia communities, and government sectors) to examine “technical and administrative efforts to increase trust online by improving the Public Key Infrastructure certificate marketplace supporting SSL and TLS.”

From the opening keynote to the final remarks, we heard from experts around the world. There were presentations on the current state of trust infrastructure and audits, the impact of recent breaches, detailed looks on some emerging solutions like Certificate Transparency and DANE, and new ideas to manage and minimize risk in key usage.

All You Need to Know About the RC4 Encryption Scheme
March 14, 2013 by Rick Andrews Attack CASC Encryption RC4 RSA SSL/TLS Vulnerability

The latest published attacks target specific algorithms used within SSL/TLS. Those algorithms are used when a client connects to a server via SSL/TLS; they’re not used when a Certificate Authority signs a certificate. The attacks demonstrate potential weaknesses in the use of the algorithms.

While interesting, the attacks don’t represent an immediate practical threat to users of SSL/TLS (including online banking, e-commerce, social networking, etc.). Such attacks require an attacker to run malicious software on a user’s computer which would connect to a particular web site and send the same message over and over again many times. In fact, if the attacker’s software could send the same message over and over 10 times per second, it would still take more than 3 years for the attack to succeed.

The Importance of Checking for Certificate Revocation
March 9, 2013 by Rick Andrews Attack CRL Identity Malware MITM OCSP Revocation SSL/TLS

Certificates are typically valid for one to three years, and during that time it’s possible that the web site owner or the CA realizes that end users should not trust the certificate. There are several cases in which this might happen, including these:

• The web site owner ceases doing business, no longer owns the domain name used in the certificate, has changed their organization name, or wishes to shut down the web server.
• The subscriber learns that an unauthorized party has gained access to the private key associated with the public key in the certificate.
• The CA learns that errors were made in authentication, the subscriber misrepresented some material info used in the authentication process, or the subscriber has violated the terms of its agreement with the CA.

When the subscriber or CA makes the decision to revoke a certificate, that decision must be conveyed to end users who encounter the certificate in use. There are two different methods for this: