Best Practices: Preparing for and
Responding to a CA Compromise
S e c u ri t y B e s t p ract ice s Whit e Paper
Table of Contents
Introduction
4
What is this?
4
CA Compromise Scenarios
4
A. Impersonation
4
B. RA Compromise
4
C. CA System Compromise
5
5
D. CA Signing Key Compromise
Potential Attacks with Fraudulent Certificates
5
Authentication
5
Encryption Eavesdropping (Man-in-the-Middle)
6
7
Fraudulent Digital Signatures
Why should I care?
8
What should I do?
8
Preparing for a CA Compromise
9
Responding to a CA Compromise
12
Impersonation
12
RA Compromise
12
CA System, CA Signing Key, and Root CA Compromise
13
Conclusions
14
About Venafi
14
3
Introduction
What is this?
The compromise of a certificate authority (CA) can enable an
attacker, or Hacker, to generate fraudulent digital certificates,
which the Hacker can use in a variety of attacks against highvalue business assets. Ultimately, enterprises might need to
replace some or all certificates issued by the CA and even
explicitly stop trusting the CA in order to protect themselves.
To avoid significant security and operational risks, enterprises
must have a plan in place for responding to a CA compromise.
This paper provides an overview of CA compromises and
provides recommended steps for preparing your organization to
respond as well as detailed steps for responding.
A Hacker who breaches a CA to generate fraudulent
certificates does so in order to launch further attacks
against other organizations or individuals. Therefore, a CA
compromise includes two phases: compromising the CA
to obtain the fraudulent certificate and using the fraudulent
certificate for other nefarious purposes.
A. Impersonation
The Hacker successfully impersonates someone else to
the Registration Authority (RA), which is responsible for
checking certificate requests and validating the identity
and authority of the requester. If the CA receives an
authorization from the RA for a request, CA issues the
Hacker a certificate with that other person’s or system’s
name in it (some CAs have additional reviews in place).
For example, Alice sends digitally-signed authorizations to
Bob for money transfers. Bob uses a certificate issued to
Alice from CA1 to verify the authorizations. Eve convinces
CA1, or another CA that Bob trusts, that she is Alice, and
CA1 issues a certificate containing Alice’s name but Eve’s
public key. Eve is now able to forge Alice’s signature on
money transfer authorizations and Bob, trusting the CA,
will verify them using the fraudulent certificate.
4
CA Compromise Scenarios
Consider the CA compromise first. A Hacker can circumvent the
security of a CA to obtain fraudulent certificates in several ways
as shown below.
This attack was successfully performed in 2001 by an
individual masquerading as a Microsoft employee and
requesting a Microsoft code signing certificate from VeriSign.1
B. RA Compromise
The Hacker infiltrates the RA and is able to authorize the
issuance of one or more fraudulent certificates by the CA.
This attack was performed in 2011 when a Hacker
infiltrated InstantSSL.it, an authorized RA of Comodo, and
successfully authorized the issuance of nine certificates
for Google, Yahoo, and other organizations.2
C. CA System Compromise
The Hacker infiltrates the CA and succeeds in using the
CA’s issuance system to issue one or more fraudulent
certificates. In this scenario, the Hacker does not obtain
a copy of the CA private key but is able to use that
key to issue fraudulent certificates. In addition, having
compromised the CA system at this level, the Hacker can
generate one or more signed but fraudulent certificate
revocation lists (CRLs), which can bolster the effectiveness
of an attack that leverages the fraudulent certificates.
Because the CA system has been compromised, it is
possible that the Hacker can also alter logs to obscure
which certificates were signed inappropriately.
This attack was performed in 2011 when a Hacker
infiltrated several CA systems at DigiNotar, a Dutch CA,
and issued over 500 certificates for organizations such as
Google, Yahoo, Microsoft, and the CIA.3
D. CA Signing Key Compromise
In this scenario, the Hacker obtains a copy of the CA signing
key, whether by stealing a copy, using a factoring attack, or
launching a brute-force attack. Once the Hacker has this
key, he or she can use it to sign fraudulent certificates and
CRLs at will. Realistically, a Hacker is much more likely to
succeed in obtaining a copy of the key than via a factoring
or brute-force attack because CAs have traditionally used
key lengths that are long enough to make factoring or bruteforce attacks infeasible. However, due to the increased
sophistication and resources of Hackers today, these latter
attacks should not be ruled out as a possibility.
The authors are not aware of any public disclosures of CA
signing key compromises. A close possible example is the
compromise of the code signing keys owned by two companies
in Taiwan that were used in the Stuxnet attack.
Potential Attacks with Fraudulent Certificates
In the next phase of the attack—which is its ultimate goal—
the Hacker uses the fraudulent certificate to impersonate a
person or system (e.g. a website) in order to gain access to
confidential data, infiltrate secured systems and/or perform
unauthorized transactions. For the Hacker to succeed in any
of these attacks, third parties must trust the CA that issued the
fraudulent certificates. This paper will refer to impersonated
parties as Subjects and the parties misplacing their trust in
fraudulent certificates as Relying Parties. The specific Relying
Party targeted by the Hacker, as well as the specific type of
attack that the Hacker wishes to launch, drives the type of
fraudulent certificate that the Hacker attempts to create when
attacking the CA.
Authentication
In an authentication attack, the Hacker attempts to
authenticate as the Subject and gain access to that entity’s
privileges. This attack is equivalent to obtaining another
user or system’s username and password and logging in as
that entity; the fraudulent certificate functions as the hacked
username and password.
5
For example, a Hacker (Eve) is attempting to breach a server
(Alice.com), which uses certificates to authenticate users and
systems that log in to it. Alice.com is the Relying Party, and
Eve must obtain a fraudulent authentication certificate with
the name of the Subject (Bob) whose account Eve wishes to
infiltrate. Alice.com will allow the Hacker to login because the
fraudulent certificate meets two criteria: 1) it is issued by a CA
trusted by Relying Party (Alice.com), and 2) it has a subject
name for a valid account.
Encryption Eavesdropping (Man-in-the-Middle)
A Hacker who wishes to read confidential information
transmitted between two parties (e.g. login passwords, email
messages, credit card information, etc.) can use fraudulent
certificates to circumvent the encryption that typically protects
those communications. For this attack, the Hacker must obtain
one or more fraudulent encryption certificates in the name of
the intended recipient of the information (referred to hereafter
as the Subject of the attack). The Hacker then inserts him or
herself in the path of communications between the Subject and
the entity they are sending information to (Relying Party) and
provides the fraudulent certificate(s) to the Relying Party. The
Hacker can then decrypt the data transmitted from the Relying
Party to the Subject because the Relying Party encrypts the
data using the fraudulent certificate. The Hacker re-encrypts
the data with the Subject’s certificate and sends the encrypted
data to the Subject.
6
For example, Bob normally logs into his banking website
(Alice.com) to perform online banking. Bob (the Relying Party)
relies on the certificate for Alice.com (the Subject) to confirm
he is connecting to the correct site. Eve (the Hacker) wants
to gain access to Bob’s account. She sets up a WiFi hotspot.
Bob uses the hotspot to connect to Alice.com but is redirected
to a server Eve has set up. Eve’s server returns a fraudulent
certificate to Bob that includes Alice.com as the subject name
but Eve’s public key. Bob, who trusts the CA listed in the
fraudulent certificate, uses that certificate to establish an SSL
connection with what appears to be Alice.com. However, the
SSL connection terminates at Eve’s server so that she is able
to see the information Bob transmits.
In order to make Bob believe he is interacting directly with
Alice.com, Eve simultaneously creates an SSL connection to
Alice.com and transparently passes information between Bob
and Alice.com so that neither party suspects that an intermediary
device is intercepting their communications. When Bob enters
a username and password to log in to Alice.com, Eve is able to
intercept the username and password. Eve can subsequently
log in to Alice.com as Bob using that username and password.
Eve is also able to view all of the other information transferred
between Bob and Alice.com during the session.
Fraudulent Digital Signatures
A certificate can be used to verify digital signatures that are
generated by a Subject using their private key. These digital
signatures may be used as attestations on documents or to
authorize specific actions. In the area of digital signatures,
Relying Parties are the people or systems who require
signatures and use certificates to validate those signatures. A
Hacker who wants to get a Relying Party to accept a fraudulent
digital signature obtains a fraudulent digital signature certificate
which lists the name of the attack’s Subject, the person or
system that can authorize the Relying Party to perform the
desired action. The fraudulent certificate will include the
Hacker’s public key, enabling the Hacker to forge signatures
with their corresponding private key.
For example, Bob is a customer at a bank that requires digital
signatures to authorize fund transfers he requests. Alice is the
person at the bank who validates digital signatures using a set
of certificate authorities she trusts. Eve would like to authorize
a fraudulent fund transfer acting as Bob. Eve compromises
a CA that Alice trusts and successfully gets a certificate that
includes Bob as the subject name but includes Eve’s public
key. Eve signs a fraudulent fund transfer using her private key
(corresponding to her public key) and sends it to Alice. Alice
checks that the certificate 1) is from a CA that she trusts and
2) has Bob as the subject name. Because both are true, she
authorizes the fund transfer.
7
Why should I care?
What should I do?
Recent incidents have demonstrated that hackers are targeting
CAs—including Comodo, StartSSL, and DigiNotar—as part of
their security attacks. In addition to these publicized attacks,
the Electronic Frontier Foundation said it found evidence of 55
cases of hacking into the systems of certificate authorities in
2010 based on analysis of CRLs4.
An enterprises’ first goal must be to minimize the probability
of a CA compromise, which is best accomplished by ensuring
that CAs, both internal and external, follow the best possible
security practices. Enterprises should review their external
CA’s business and security processes, making sure that
regular, third-party audits are performed to validate that
those processes are being followed. The same operational
and security processes should be enforced for internal CAs,
including regular third party audits.
Because SSL has been adopted so broadly, digital certificates
function as a critical security component of all corporations’ and
government agencies’ security systems. This creates significant
risk of security breaches and operational stoppages if the CA
that signed those certificates is compromised.
For example, following the compromise of DigiNotar, the
social security, police and tax organizations’ websites within
the Dutch government were considered unsafe and effectively
unusable until new certificates could be installed from another
CA. Officials were forced to recommend that pen and paper
be used for secure communications until certificates could be
replaced on those and other servers5. In addition, because the
DigiNotar root certificate was considered unsafe, they must
remove that root certificate from all trust stores, an operation
that involves far more systems than those with standard
certificates (certificates issued to people or systems).
In addition, although the recently breached CAs were thirdparty CAs, external to organizations that use their certificates,
the risk is not limited to external CAs. Many organizations
operate their own internal CAs, which issue certificates used
to secure their internal operations, systems, applications, and
data. In fact, many organizations have more internally-issued
certificates than certificates issued by external CAs, and these
certificates are often used for mission critical applications.
Consequently, the impact of a compromise of an internal CA
could be as significant as the compromise of an external CA, if
not more so.
Without proper recovery plans put in place ahead of time,
replacing hundreds, thousands, or tens of thousands of
certificates in the wake of a CA compromise can take days
or weeks, effectively bringing a corporation or government
agency to a halt during that time. Consequently, organizations’
disaster recovery plans must include processes for
responding to a CA compromise.
8
Next, organizations must ensure that they discover a CA
compromise as quickly as possible and are provided sufficient
details so that they know what remedial action is necessary.
CAs must have mechanisms to detect security breaches
and rapidly and accurately communicate information about
any breach that occurs. DigiNotar first discovered a breach
weeks before it became public but did not disclose the incident
when it occurred6. The compromise did not become public
until an outside party reported an anomaly when connecting
to Google on August 28, 2011. Only then did it become clear
that hundreds of fraudulent certificates had been issued in
July 2011. By that time, the attackers were able to use the
fraudulent certificates for their objectives. CAs must employ all
possible detection mechanisms and perform regular manual
operational sanity checks. They must also have clear policies
and plans for communicating any incidents.
In parallel with ensuring the security and transparency of their
CAs, organizations must ensure they are prepared for a CA
compromise and have specific plans for responding to a CA
compromise. The following sections provide recommendations
to prepare for a CA compromise and for responding to various
compromise scenarios.
Preparing for a CA Compromise
Organizations can significantly reduce the business continuity impact of a CA compromise by properly preparing ahead of time. The
following diagram provides a summary of the steps that must be taken. The sequence in which these are performed may different
depending on the organization.
The following table, pages 11 - 12, details several steps, processes, and policies organizations can put in place to minimize the impact
of a CA compromise if it occurs.t
9
CA
Subject
Relying
Party
Develop, Communicate, and Track Compliance with Certificate Policies and Procedures: The
installation and management of certificates and private keys is generally very distributed
within enterprises, where installation and oversight typically falls to the each administrator
responsible for the machines and applications where the certificates are deployed. This
increases the possibility that best practices will not be followed. Consequently, it is
important to define, communicate, and educate personnel on clear policies and procedures.
Recommendations for these policies and procedures are provided in the preparation steps
below as well as other best practices from Venafi.



verall Response Plan: Organizations must have an overall CA compromise response plan. This
O
plan must identify key points of contact (who should be contacted first in case a compromise
is detected), delineate roles and responsibilities, provide a communications plan (to Subjects,
Relying Parties, executives, etc.), specify a certificate replacement plan, provide a CA migration
plan, and support other elements described in this document.






Preparatory Steps
A.
B.
C.
ducate: Responding to a CA compromise involves multiple stakeholders and roles. A response
E
will be more successful if individuals in each of those roles are educated beforehand. Here are
some examples:
1.
CA Management Personnel: Provide education on monitoring for compromise events a
nd procedures for taking remedial action (including communication plans) if a
compromise occurs.
2.
Certificate Owners (Subjects): Ensure that all certificate owners understand the
consequences of a CA compromise and the importance of maintaining up-to-date contact
information so that they can be notified in case of a compromise. In addition, certificate
owners should understand the steps they would take to rapidly replace their certificate(s)
if a compromise occurs.
3.
elying Parties: Ensure that all Relying Parties (i.e. owners of systems that check
R
certificates to authenticate or communicate with other systems) understand the
importance of configuring all systems to check revocation status. These checks ensure
that systems do not trust certificates that have been revoked by the issuing CA. If
revocation checking is interfering with operations, Relying Parties should notify the central
Public Key Infrastructure (PKI) organization to determine ways of addressing the issues
without disabling the checking. Relying Parties should also be aware of the roots they are
trusting so they can respond to a root compromise if necessary.
4.
xecutives: PKI and cryptography are not generally well understood by executives nor
E
by general IT practitioners. It is therefore helpful to educate executives on how and why
PKI is used (what security function is it providing and the data/systems it is protecting),
the importance of proper management, and the potential security and operational risks,
including CA compromises.
5.
elp Desk: It is critical that your help desk be educated and prepared for a CA
H
compromise. CA compromises occur unexpectedly and cause a lot of confusion and
inquiries. If your help desk is prepared ahead of time, they can be quickly briefed on
the situation after a compromise and provide accurate and actionable information to
stakeholders in your environment.
D.
eview CA Security and Communications: Once you have a complete list of all CAs in use in
R
your environment—which may involve replacing certificates from unapproved CAs—review
the security practices for each CA (internal and external) to assure yourself that the CAs
are minimizing the risks of compromise. Review how each CA is monitored for potential
compromise and the response and communication plans in place in case of a compromise.
Ensure that the CA knows who within your organization to contact. It is important to review the
security of your CAs (internal and external) on a periodic basis.

Transition Plan: If a CA is compromised, you must obtain certificates from another CA. It is
CA
best to have plans in place for the new CA before a CA compromise occurs. For external CAs, it
may good to maintain a relationship with multiple CAs so that contractual relationships are in
place prior to a CA compromise event that requires you to move away from a vendor entirely. For
internal CAs, implement a plan for rapidly establishing a new CA in the event of a compromise.

E.
10
F.
stablish and Maintain Certificate Inventory: An important step in preparing for a CA
E
compromise is building a comprehensive inventory of the certificates and associated private
keys deployed in your environment. This includes tracking precisely which CAs are used by
which platforms and applications so that appropriate action can be taken if one of them is
compromised. A comprehensive inventory also enables you to identify all certificates that need
to be replaced in the case of a compromise and to validate that they are actually replaced.
good first step in establishing an inventory is requesting a list of issued certificates from your
A
known CAs. However, this will likely not account for all certificates in use in your environment,
as certificates from other, unknown CAs or self-signed certificates of which you are not
aware may have been installed. It is often prudent to perform a manual inventory (asking
all administrators to report the certificates they are responsible for) or automated inventory
(performing automated network and/or file scans to discover certificates).
G.
erify only Approved CAs: Once you have compiled an inventory of all relevant certificates, it is
V
important to verify that only approved CAs are being used. The use of unapproved CAs creates
risk. If an unsecure CA is used, it increases the likelihood of compromise. It is also important to
verify that the correct CA is being used for each application type. For example, external-facing
systems should use certificates from your 3rd party trust provider and internal-facing systems
use certificates from your internal CA.
nsure that you are not using a root CA to issue end-entity certificates. If a root is being used to
E
issue end-entity certificates, replace those certificates with certificates from an Intermediate CA.
H.
Establish and Maintain List of Owners: While creating an inventory of certificates, it is critical to
identify owners for each certificate and contact information. This enables you to rapidly contact
all appropriate owners if a compromise occurs so they can take action. Because certificate
deployments and owners change, it is important to implement a system for keeping inventory
and ownership information up to date.
I.
ertificate Replacement Plan: If a CA is compromised, that CA’s certificate must be revoked and
C
all of the certificates issued by the CA become invalid and must be replaced. In environments
with large numbers of active certificates, large-scale replacements can be very disruptive and
can cause operations to stop for extended periods of time. Therefore, it is critical to have a welldefined plan for replacing certificates in a rapid yet orderly fashion.
1.
n inventory and list of owners serve as the foundation for a rapid response by ensuring
A
that all certificate owners can be contacted when a compromise occurs. Certificate owners
must also understand the steps for replacing certificates. However, since many certificate
owners do not perform certificate operations frequently, they will likely need assistance.
It is therefore important to have a plan for staffing a help desk to handle the large number
of support requests as all certificates are replaced. If high priority systems and certificates
have been identified during the inventory process, the replacement plan should also
include steps for ensuring those certificates are replaced early in the process.




2.
J.
nforce Revocation Checking: Ensure that revocation checking is enabled and mandatory (i.e.
E
operations or transactions cannot proceed if the status of the certificate cannot be checked
due to an unavailable CRL or OCSP responder). All standard builds and images (e.g. operating
systems and applications) should have revocation checking enabled. In addition, wherever
possible, application configuration management systems should be used to ensure that
revocation checking is not turned off.

oot Inventory: Establish an inventory of all roots that are trusted in your organization and
R
establish a plan for replacing them if necessary. This step is important in case a root CA is
compromised and a root must no longer be trusted.

K.
inally, it is important to have a method for monitoring the replacement of certificates so
F
that it is clear which systems are not safe, where problems are occurring and when the
process is complete. This monitoring and tracking also makes it possible to report back
to executives and other stakeholders. A target timeframe should be set for the amount
of time required to replace certificates and get systems and business applications back
in operation.
11
Responding to a CA Compromise
The necessary steps for responding to a compromise depend on the type of incident as well as the “role” an organization is playing
in the attack (CA, Subject, Relying Party, or potentially all of these). However, the following table shows the high-level steps that
an organization should take in response to each of the four types of CA compromises irrespective of the organization’s role. A fifth
scenario is added for Root CA Compromise, which requires different steps than an Intermediate CA Compromise.
Revoke Counterfeit
Certificates
1. Impersonation
2. RA Compromise
3. CA System Compromise



4. CA Signing Key Compromise
Revoke CA Cert
Replace All Certs
from CA
Remove Root Cert
from Relying Parties






5. Root CA Compromise

The following steps provide details for responding to each of the scenarios outlined above.
Impersonation
If a Hacker obtains a fraudulent certificate by impersonating another entity to the RA, the following steps are recommended:
Steps
CA
A.
Revoke the Fraudulent Certificate
B.
Notify the Subject of the Fraudulent Certificate


C.
otify potential Relying Parties to ensure they are checking for revocation. This notification may
N
be provided through direct communication or public relations announcements.

D.
otify vendors of software or systems used by Relying Parties (e.g. browsers). If the potential
N
use of the fraudulent certificate will have a high impact, it may make sense for software and
system vendors to explicitly block the use of the fraudulent certificate.

E.
nsure that revocation checking is enabled and mandatory (i.e. operations or transactions
E
cannot proceed if the status of the certificate cannot be checked due to an unavailable CRL or
OCSP responder).
Subject
Relying
Party

RA Compromise
If a Hacker compromises an RA to obtain a fraudulent certificate, the following steps are recommended:
12
Steps
CA
A.
Revoke the Fraudulent Certificate

B.
evoke the credentials of the compromised RA (issuing new credentials if the RA will resume
R
its duties).

C.
Carefully check all logs to ensure that all fraudulent certificates have been identified and revoked.
D.
Notify the Subject(s) of the Fraudulent Certificate(s)


E.
otify potential Relying Parties to ensure they are checking for revocation. This notification may
N
be provided through direct communication or public relations announcements.

F.
otify vendors of software or systems used by Relying Parties (e.g. browsers). If the potential
N
use of the fraudulent certificate will have a high impact, it may make sense for software and
system vendors to explicitly block the use of the fraudulent certificate.

G.
nsure that revocation checking is enabled and mandatory (i.e. operations or transactions
E
cannot proceed if the status of the certificate cannot be checked due to an unavailable CRL or
OCSP responder).
Subject
Relying
Party

CA System, CA Signing Key, and Root CA Compromise
The diagram below summarizes the recommended steps that should be followed if a Hacker compromises a CA system or signing key
on an Intermediate or Root CA.
Steps
CA
Subject
Relying
Party
A.
stablish a Clear Understanding: It is important to have accurate information about what
E
occurred so that the proper remedial steps can be taken.



B.
ctivate Help Desk: Establish a point of contact or help desk to answer questions and provide
A
support to system administrators and other individuals responding to the CA compromise.



C.
evoke Certificates: Revoke all non-expired certificates issued from the CA and issue a final
R
CRL. Revoke the certificate of the compromised CA(s).

D.
ctivate New CA: Depending on your response plan you may need to activate a new CA within
A
your environment, request certificates from a different CA from an existing vendor, or establish
a relationship with a new CA vendor.


13
14
E.
otify: Ensure that the following stakeholders are alerted of the situation and the steps that
N
will be taken to respond:
a.
ubjects: Notify all Subjects who have been issued certificates from the compromised CA
S
that their certificate will need to be replaced and provide instructions on how to replace
those certificates.
b.
elying Parties: Notify potential Relying Parties that a compromise occurred and that
R
new certificates will be issued to Subjects they are interacting with. Ensure they are
checking for revocation so that they do not accept and trust an invalid certificate. If a root
CA was compromised, provide instructions to Relying Parities for removing the trusted
root certificate of the compromised CA. If a new root or chain will be required by Relying
Parties to validate the new certificates being issued to Subjects, provide instructions
on where to acquire and how to install the new root/chain. These notifications may be
provided through direct communication or may require public relations announcements
depending on the scope of the compromise.


endors: If you are a public CA with your root distributed by software vendors (e.g.
V
browser vendors), notify those vendors. If the potential use of the fraudulent certificate
will have a high impact, it may make sense for the software and system vendors to
explicitly block the use of the fraudulent certificate.
c.
F.
eplace Certificates: Replace all certificates from the compromised CA with new certificates
R
from a different CA. For internal CAs, this may involve setting up a new CA. For external CAs,
this may involve enrolling for new certificates.
G.
emove Roots: If a root CA compromise occurred, remove the root certificate for that CA from
R
all trust stores.

H.
I nstall New Roots/Chains: If a new root certificate or chain is required to validate new
certificates being issued to Subjects, install this root certificate in all necessary trust stores.

I.
evocation Checking: Ensure that revocation checking is enabled and mandatory (i.e.
R
operations or transactions cannot proceed if the status of the certificate cannot be checked due
to the unavailability of the CRL or OCSP responder.)

J.
alidate Replacement: Implement processes to automatically validate that certificates and
V
roots have been properly installed/replaced and are operational.


K.
rack and Report: Establish a reporting on the progress of replacing certificates so that
T
business application owners, executives, and other stakeholders have accurate information
about the status of the environment.



Conclusions
About Venafi
Because SSL is so broadly relied upon to secure systems and
data in all organizations (commercial and government), a CA
compromise can have disastrous effects. Recent events—
such as Comodo, StartCom, and DigiNotar—
have shown that hackers are resorting to CA compromises as
a strategic tool in their attacks. Consequently, organizations
must educate themselves (and all of their stakeholders) and
put concrete plans in place to both prepare for and respond to
a CA compromise.
Venafi is the inventor of and market leader in Enterprise
Key and Certificate Management (EKCM) solutions. Venafi
delivered the first enterprise–class solution to automate
the provisioning, discovery, monitoring and management of
digital certificates and encryption keys—from data center
to the cloud and beyond—built specifically for encryption
management interoperability across heterogeneous
environments. In addition to addressing a large number of
other challenges in managing encryption enterprise-wide,
Venafi’s expertise and solutions help organizations prepare
for and rapidly respond to a CA compromise.
Endnotes
1technet.microsoft.com/en-us/security/bulletin/ms01-017
2www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
3www.rijksoverheid.nl/bestanden/documenten-en-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1/rapport-fox-itoperation-black-tulip-v1-0.pdf
4Source: New York Times, September 12, 2011 (www.nytimes.com/2011/09/13/technology/hacking-in-netherlands-points-to-weakspot-in-web-security.html?pagewanted=2&_r=1&ref=business)
5Source: New York Times, September 5, 2011 (www.nytimes.com/2011/09/06/technology/hacking-in-the-netherlands-broadens-inscope.html?_r=1)
6“Interim Report DigiNotar Certificate Authority breach”, Fox-IT, September 5, 2011 (www.rijksoverheid.nl/bestanden/documentenen-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1/rapport-fox-it-operation-black-tulip-v1-0.pdf)
Copyright © 2012 Venafi, Inc. All rights reserved. Venafi and the Venafi logo are trademarks of Venafi, Inc. in the United States and other countries. All other
company and product names may be trademarks of their respective companies. This document is for informational purposes only. Venafi makes no warranties,
express or implied, in this summary. Covered by United States Patents #7,418,597, #7,568,095, #7,650,496, #7,650,497, #7,653,810, #7,698,549, #7,937,583, and
other patents pending.
Part number: 1-0011-0212
15
Worldwide HQ
126 W Sego Lily Drive #126
Sandy, Utah 84070
USA
+1 801.676.6900
+1 801.676.6901
EMEA HQ
Lily Hill House, Lily Hill Road
Bracknell, Berkshire RG12 2SJ
United Kingdom
+44 (0) 1344 317980