Posted 12 Things to Look for in a Managed PKI Solution, Part 1 on Blog
This is the first part of a four-part series covering twelve fundamentals for choosing a managed PKI solution, and questions to ask in the buying process.
The purpose of this blog is to make you aware that not all Managed PKI providers are the same. In fact, there are some pretty significant differences between DigiCert’s offerings relative to the competition that you wouldn’t see by comparing data sheets. DigiCert’s key advantage is that the Symantec Managed PKI was designed as a service from the ground up as opposed to the competition, that have built their service from legacy on premise software. While the data sheets might look similar, over the next few weeks, we will highlight some of the fundamental advantages of Symantec Managed PKI.
When it comes to Public Key Infrastructure (PKI), organizations have two deployment options: 1) they can opt for an in-house on-premise solution, or 2) a cloud-based service like Symantec Managed PKI*. There are many benefits to a Managed PKI Service, including faster time to deployment, lower total cost of ownership, and leveraging operational excellence.
1. Shared vs. Dedicated customer PKI roots
DigiCert performs an independent 3rd party audited Root Key Generation Ceremony (RKGC) for every customer we bring on to the service. In fact, DigiCert performs over 1000 key signing ceremonies every year; more than any other Managed PKI provider in the world. Some providers will “partition” their PKI, and host multiple customers under the same Root. The Root CA is your trust anchor; and it shouldn’t be shared.
One of the key benefits of a Managed Service is that your Certificate Authority (CA) can be operational much faster than trying to set one up on premise. DigiCert can bring a new customer on to our Managed Service in as few as 10 days from the processing of your Purchase Order. Under special circumstances, we can have it operational even sooner. Competing service providers are typically operational in 8-12 weeks, and don’t always meet that deadline.
3. Access to Public trust
In addition to your own private root of trust, DigiCert’s standard offering also provides you with access to a public root, and an Adobe Approved Trust List (AATL) , all accessible and managed from the same web based Administrative portal. Access to these additional roots enables organizations to meet a variety of additional Enterprise use cases that require external trust. For example, trusted e-mail digital signatures, Adobe document signing, etc. Competing solutions typically only offer private roots of trust, or require you to issue publicly trusted user certificates from a separate portal.
4. Broad revocation support
DigiCert supports both Online Certificate Status Protocol (OCSP) and traditional Certificate Revocation Lists (CRL) as part of our standard service. Some of the competing solutions will only offer CRL based checking, and charge extra for OCSP.
Questions to Ask
Here are some questions to ask your potential Managed PKI service provider:
•Do you offer you a shared “partitioned” PKI root, or do you only offer dedicated PKI roots?
•Do you perform a root key generation ceremony for every customer you bring on to your service?
•How quickly is the service operational from the time you process my purchase order?
•Do you have a proven track record of meeting your stated timelines?
•Can you offer me different roots of trust for all of my Enterprise use cases from a single Administrative portal?
•Do you include both OCSP and CRL based revocation checking capabilities as part of your service, or is it an additional charge?
Part 2 in this series will cover some of the DigiCert advantages around Administration and Deployment. Would you need to open a support ticket every time you make an Administrative change to the CA? I'll cover this and two other fundamentals for choosing a PKI provider in the next post.
*On October 31, 2017, DigiCert, Inc. acquired from Symantec Corporation the business of providing and supporting Symantec’s Website Security and PKI products and services.
Mar 07 2018, 9:10 AM
Posted Certificate Authority Authorization Checking: What is it, and why should you care? on Blog
The Public Key Infrastructure (PKI) ecosystem relies on root certificates issued by various certification authorities (CAs) like Symantec. This is what browsers use to decide which websites can be trusted, and which ones are not trusted.
Up to now, any CA can issue a TLS certificate for any domain. That’s how the system works, and it’s good in the sense that it gives website owners and operators options to change CAs at their discretion. The downside to this is that certificate issuance can happen without the knowledge of website operators, either by mistake or intentionally by malicious actors.
A number of technologies have been created in an attempt to highlight instances of “unknown” issuance, such as Certificate Transparency. These have been effective in making the internet a safer, more trustworthy place but they are reactionary measures – only .allowing website operators to address the issue after it’s happened.
But is it possible to prevent certificates from being mistakenly or inappropriately issued? Yes. Enter: Certification Authority Authorization (CAA).
CAA prevents unknown certificate issuance by:
1.Allowing domain owners to specify which CAs are authorized to issue certificates for their domains; and
2.Giving CAs the ability to check this authorization before issuing a certificate.
In this article, we’ll explain how CAA works, and why making CAA checking mandatory is a good move for both customers and CAs.
A Certification Authority Authorization (CAA) record is a DNS Resource Record which allows a domain owner to specify which CAs are authorized to issue certificates for their domain(s) and, by implication, which aren’t.
The idea is that a CA will check the CAA record(s) for a domain before issuing a certificate. If it finds that a domain has no CAA record, then it’s free to issue a certificate for it if all other authentication checks succeed. However, if it does encounter one or more CAA records, then the CA can only issue a certificate if it’s named in one of the records, indicating that it is authorized to issue a certificate for that domain. The whole process is designed to prevent CAs from unauthorized certificate issuance requests by unauthorized parties or bad actors.
Symantec has been checking CAA records for years, but it’s not a common practice. There are two reasons why CAA checking isn’t widely practiced:
1.Many domains don’t have a CAA Resource Record; and
2.Checking CAA records is not mandatory.
Because it may take some work to create a CAA record, it’s a matter of customers or website operators consciously opting-in, not opting-out. Many domain owners use a DNS hosting provider and CAA is not yet supported in some DNS implementations.
This is why CAA records are expected to be used by most high-value domains. These enterprises keep CAA records for their domains because they limit inappropriate (or malicious) certificate requests, and makes it easier to enforce company policies i.e. only using a particular set of CAs.
Of course, CAA checking has its limitations.
First, a newly-issued CAA record does not invalidate any previously-issued certificates that may have been issued by a different CA than the one named by the domain owner. Second, it doesn’t flag whether a certificate presented by a web server is a legitimate certificate for that domain.
Furthermore, in order for CAA checking to be effective, all CAs need to be doing it; it doesn’t work if only one or two CAs are checking CAA records as matter of process. CAA checking must be widely adopted if it is to serve its purpose, but the good news is that more than ninety percent of CAs (who are members of the CA/Browser Forum) are in favor of it.
In February 2017, the CA/Browser Forum passed a ballot (on which Symantec voted in favor) requiring all CAs (even those who aren’t a member of the Forum) to check for a CAA record as part of the certificate issuance process for each domain. In accordance with RFC 6844, CAs can no longer issue a certificate for a domain unless:
1.The CA does not find any CAA records for the domain
2.The certificate request is consistent with the applicable CAA Resource Record(s)
The rule is effective as of 8 September 2017. You can read the ballot in full here.
Mandatory CAA record checking requires CAs to abide by the rules set out in specific CAA records, giving domain owners more control over certificate issuance. This makes it easier for companies (especially larger ones) to enforce a certificate issuance policy across business units. With CAA records applicable to every domain, a company can specify a set number of CAs, knowing no other CA can issue a certificate to its domains. This will help reduce the risks of certificate issuance by unauthorized CAs and help create a more secure and transparent online ecosystem.
For more information on CAA with Symantec Certificates go to Symantec Knowledge Center
Mar 07 2018, 9:10 AM