The basic role of a certificate is to bind a name (e.g., www.venafi.com) to a public key. There are a lot of other pieces of information in a certificate but the Subject and Public Key fields are its raison d’être—what a recipient of the certificate (machine or person) cares about.
When a machine or person receives a certificate, they’ll want to ensure it is valid by checking that the issuer (certificate authority or CA) is an entity they trust, the signature is valid, the certificate is not expired or revoked, etc. But at the end of the day, they care most about whether the name in the Subject matches the person or system they’re interacting with and they want to use the public key for that interaction.
If an attacker wants to impersonate another system or person (e.g., www.venafi.com in the certificate above), they need to get a certificate with the targeted name and their (the attacker’s) public key from a CA that the recipient trusts. Since certificates are trusted credentials for authentication, CAs are attractive targets for attackers. If they can trick the CA into thinking they’re someone else, or actually compromise the CA to get it to issue a rogue certificate, they’ve got the equivalent of a key that unlocks somebody else’s doors.
Certificate authorities (CAs) issue certificates. It is their responsibility to verify the identity of entities to which they issue certificates. In a PKI, the role of the person or process that verifies identities prior to issuance by a CA is called a registration authority (RA). The RA can be within the same company as the CA or in a separate company. If the certificate is being issued to a person, the RA must ensure that the person has the name/identity being placed in the certificate (e.g., Bob Simms at Venafi or CN=Bob.Simms; O=Venafi). If the certificate is being issued to a system or application, the name is typically a unique address, such as a DNS address (e.g., www.venafi.com). In this case, the RA has to ensure that person is authorized to request a certificate for that address—for example, making sure the organization they work for owns/controls that domain and that the organization has authorized the requester to request certificates for that domain.
There are a number of different ways an attacker can attempt to get a rogue certificate from a CA, including:
There are two types of fallout from these attacks. First, if the rogue certificate in question has the name of one of your domains or employees in it, the attacker can act like they are part of your organization and do various sorts of harm to your organization or your customers/partners. Second, if the compromised CA is one you use for the issuance of your certificates, you may have to rapidly replace all of your certificates. The Dutch government, for example, had to scramble to replace all of their certificates when DigiNotar was compromised because they were a big DigiNotar customer. This caused significant fallout to the operations and reputation of the Dutch government.
The moral of the story is you don’t have to be the target of a rogue certificate attack to be significantly impacted by it. For this and other reasons, you must always have the capability and be prepared to rapidly and non-disruptively replace all of your certificates.
In the meantime, please explore more of our solutions