Skip to main content
banner image
venafi logo
Education Center Detail

Education Center - Audit Workpaper

Audit Workpaper

This article is an excerpt is from a System Access – Access Control, User-to-Computer, & Computer-to-Computer Authentication Audit workpaper. It is intended to help you audit your certificates and keystores for the purposes of security or auditing.


There are two primary risks created by improper SSL certificate and key management: 1) unauthorized users or computers gain access to sensitive information, networks, systems, or applications and 2) downtime and system outages.


Secure Socket Layer (SSL) and Transport Layer Security (TLS) serve as the primary security mechanisms for protecting usernames, passwords, and other sensitive data transferred in and out of corporate networks. SSL and TLS require that certificates and private keys be deployed on servers and user systems in order to authenticate computers (i.e. acting as an ID badge for a computer) and users, and to encrypt data in transit. Improperly managed certificates and keys create security and operational risk.

Information security risk for SSL/TLS certificates and private keys is created as a result of the following:
  • Weak cryptographic key lengths enable keys to be derived, or guessed, by attackers. Weak key lengths are similar to weak passwords that can be guessed.

  • Weak cryptographic algorithms enable attackers to counterfeit certificates and impersonate systems or users. Weak algorithms are also similar to a weak password that can be hacked.

  • Long rotation periods, in which keys are not changed regularly, allow former employees computer/system access to secure systems, applications and data that they should not have access to. Long rotation periods for keys are similar to user passwords that are not changed regularly.

  • Certificate authorities (CAs) are entities that issue SSL/TLS certificates. Compromised CAs enable attackers to counterfeit certificates. Counterfeit certificates are comparable to a set of house keys that were copied without oversight or approval. A private key compromise allows attackers to authenticate themselves as the owner of the private key. Private key compromise is similar to allowing access to passwords written on Post-It notes.

Operational risk for SSL/TLS certificates and private keys is created by the following:
  • Expired certificates cause system outages. Every certificate has an expiration date after which the systems will no longer allow the certificate to authenticate the system or be used.

  • Certificate authority (CA) compromises require operations to be stopped until all certificates from that compromised CA are revoked and replaced by an alternate CA. If an organization is not prepared to replace certificates in case of a CA compromise, it can take days or weeks to locate and replace all certificates, with critical services and operations unavailable during that time.


In order to mitigate the risks identified above, the following controls regarding private keys and SSL certificates must be in place:

  • Documented and communicated enterprise key and certificate management (EKCM) policies exist and are updated annually or as frequently as new risks warrant.

  • An accurate, system-generated inventory of deployed SSL/TLS certificates and private keys is actively maintained for completeness. Regular verification scans are performed.

  • The attributes of each certificate and private key are monitored to ensure it is in compliance with policy. This includes, at minimum, adherence to the following:

    - Key lengths greater than the minimum size specified by NIST {security}

    - Certificate signing algorithms in use are approved by NIST {security}

    - Certificate validity periods (rotation periods) are 1 year unless specific exception is granted {security}

    - Certificates and keys are replaced no less than 30 days prior to expiration to avoid unplanned downtime {availability}

    - Only certificates from approved certificate authorities are in use {security}

    - Private key management procedures exist and are updated regularly {security}

  • Detailed logs of all certificate and key management operations are maintained, reviewed, and secured as part of audit processes.

  • A documented CA compromise recovery plan exists and is updated regularly. The CA compromise recovery plan should be tested/simulated with all appropriate participants.

Source Testing Documents

Any relevant procedure documents, inventory report with appropriate attribute detail, org charts, etc.


100% of SSL certificates and private keys are in scope for this control. The frequency of this control is ongoing and the risk rating is high. A test of XX is performed over the period of xx/xx/xx to xx/xx/xx as per the work steps.

Testing Methodology

EKCM policies and procedures are reviewed in detail for completeness and to ensure that audit worksteps cover all applicable areas. This includes a review of private key management procedures. Procedures for maintaining a comprehensive system-generated inventory and attributes for all certificates and private keys in the inventory are reviewed in detail. Beware of inventories manually generated and maintained in a spreadsheet as these inventories can be suspect and incomplete. A statistically–significant sample size of audit logs are reviewed based on randomly selected certificates and private keys; however the logs for the operations on those selected certificates and private keys are reviewed in detail. CA compromise preparation and response plans are also reviewed in detail for completeness.

Worksteps Performed
  1. Review corporate and business unit-specific EKCM policies and processes to ensure they cover current best practices and standards. Policies should also define procedures for reviewing and remediating or approving exceptions. Policies should at a minimum include provisions for:

    • Minimum key lengths (e.g. 2048-bits); should incorporate latest recommendations by NIST (SP 800-131a, which specifies minimal key lengths).

    • Approved cryptographic algorithms; should incorporate latest recommendations by NIST (e.g. FIPS).

    • Maximum certificate and private key validity (rotation) periods. Due to average administrative turnover rates, a one year validity period is recommended.

    • Identification of approved certificate authorities (CAs); including guidelines for selecting proper CA. Guidelines include the selection of an internal versus an external CA.

    • Approved trusted root certificates which are used by systems to validate certificates.

    • Certificate management policies; including:

      - Enrollment procedures for new and renewed certificates which should also include required approvals.

      - Registration authority procedures (due diligence procedures)

      - Minimum renewal periods. Determine the number of days prior to certificate expiration that certificates are replaced to avoid in-service downtime).

    • Private key management policies, including:

      - Whether administrators are able to directly access private keys

      - Allowed keystore types (software- versus hardware-based keystores)

      - Separation of duties (e.g. separation between key custodians and application owners)

      - Dual control (approval of operations)

    • Logging requirements; to enable audit of all key management operations

    • Roles and responsibilities of all stakeholders (application owners, key custodians, CA admins, etc.)

    • Revocation checking is enabled and enforced on all systems that act as relying parties

      Review communications and training procedures for EKCM policies to ensure that all critical stakeholders have the proper knowledge and tools.

  2. Verify that an accurate inventory of all certificates and private keys, as well as trusted root certificates, is being maintained through the following steps:

    • Network scans are performed periodically (frequency defined by corporate policy) on all network segments to ensure that all network-facing (server-side) certificates are discovered and accounted for.

    • Onboard scans (e.g. checking file systems) are performed periodically (frequency defined by corporate policy) on all mission-critical systems to ensure that all client-side certificates are discovered and accounted for.

    • Well-defined procedures are in place for the reliable registration of certificates and private key instances that cannot be discovered by network or onboard scanning.

    • All locations for certificates and private keys are identified (the same certificate and private key can be copied to multiple locations, e.g., for load balancing environments).

    • All owners or contacts are identified (with provisions for keeping ownership information up to date) so they can be contacted if needed (e.g., in case of a CA compromise).

    • All relevant attributes of the certificates are collected as part of the inventory (e.g., key lengths, validity periods, etc.)

  3. Review attributes for certificates and private keys in inventory to ensure they comply with corporate EKCM policies. Control values to check for production keys and certificates include:

    • Key lengths are 2048-bits or greater

    • Signing algorithms for certificates are SHA2 or stronger

    • Certificate validity periods (the time between issue and expiration date) are equal to 1 year unless specific exception is granted by information security group for maximum of 3 years

    • All certificates are not expiring in less than 30 days to avoid downtime via in-service expiration

    • All certificates are issued by approved certificate authorities

    • Wildcard certificates (certificate which can be used on a range of systems, such as * are used only where required by operational constraints and requirements If out of compliance situations are identified, ensure that violating certificates and private keys are replaced as soon as possible and determine what procedural breakdowns occurred so they can be remedied.

  4. Review private keys management procedures to ensure that:

    • Administrators should not have direct access to private keys unless documented technical constraints require it (i.e., the technologies where the private keys are stored do not provide for private keys security and no alternative automated key management solutions exist to eliminate direct access)

    • Private keys that have been directly accessed by administrators are replaced when those administrators are reassigned or leave the organization

    • Strong credentials are being used for access to the keystores where private keys are stored

    • Separation of duties are enforced (controlled via granular access controls)

    • Dual control is enforced (controlled via workflow review and approvals)

    • All management operations are logged to a secure audit log

  5. For SSL certificates and private keys not subject to established production policies (i.e. test and development), validate that controls are in place to ensure these certificates and private keys are never moved into production domain.

  6. Validate Documented policies and procedures are in place to prevent, prepare for, and respond to a CA compromise:

    • Security and operations of internal certificate authorities is regularly audited and appropriate audit documentation is provided from the external certificate authorities that are utilized.

    • Backup certificate authorities are in place to enable rapid recovery from a CA compromise.

      - For external CAs, it is recommended that active contractual relationships are maintained with more than one vendor. It is plausible to negotiate a contractual relationship with a new vendor while attempting to recover from a CA compromise. It is also a best practice to use certificates from all vendors to ensure that a cutover from one CA to another is rapid.

      - For internal CAs, it is recommended that an alternate CA be activated but kept offline, for security purposes, until needed.

    • Preparation and recovery plans for a CA compromise have been documented and communicated. These plans should include:

      - Reliable procedures for rapidly replacing all certificates issued from each CA currently in use

      - Reliable procedures for rapidly removing trusted root certificates from all applicable trust stores in case of a root CA compromise. Note, this must be applicable for CAs that are not directly in use by your organization since your systems and users rely on certificates from other companies.

      - Technologies and processes for tracking and monitoring the progress of replacement operations so it is clear when all affected certificates and systems have been remediated

      - Roles and responsibilities during a CA compromise response (e.g., situation assessment, communications, help desk, new key pair generation, RA, progress tracking and monitoring, etc.)

  7. Evaluate the effectiveness of implemented EKCM controls, by reviewing performing a sanity check of implemented policies and controls against Effectiveness, Efficiency, Confidentiality, Integrity, Availability, Compliance, and Reliability. Also review audit logs of a sampling of certificate and private key management operations, ensuring dual control, separation of duties, no administrator access to private keys, timely replacement of keys, and other security related criteria meet the EKCM policy requirements.

    Evidence: Provide appropriate screen shots, test results and graphical reports validating population size, management effectiveness and scan and validation results.

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud

Venafi Cloud manages and protects certificates

* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
* Please fill in this field
* Please fill in this field
* Please fill in this field

End User License Agreement needs to be viewed and accepted

Already have an account? Login Here

get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more