Managing The Local Administrator Password - Part 3 - The Implementation

In this post I outline a step by step guide on implementing the solution. This post builds on the previous one.

This is mostly a condensed version of the author’s documentation with addition of some items that either I found unclear or were not covered by the author. 

In any case you should read the full documentation found here:

http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789/file/96116/1/Documentation.zip

WARNING: The solution requires schema extension and this should never be taken lightly so do test properly and proceed at your own risk. 

The steps described in this section can be carried out on a Domain Controller or a management workstation. 

1. Install the CSE including the “Management Tools”

This installs: 

  • AdmPwd.ps PowerShell module 
  • GPO templates (AdmPwd.admx and .adml) 

Note: I tested this on a domain with a local GPO store. If you are using a Central Store you should check if the templates have been copied. 

The following to steps are required for Windows 2008 and 7. Windows 2012 comes with .Net4 installed and enabled.

A) Download and install .Net4: http://www.microsoft.com/en-us/download/details.aspx?id=17718

B) Configure PowerShell to load .Net4: 

Create a file named  “PowerShell.exe.config” in “\windows\system32\WindowsPowerShell\v1.0\” with the following content:

<?xml version="1.0"?>
<configuration> 
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0.30319"/>
        <supportedRuntime version="v2.0.50727"/>
    </startup>
</configuration>

Reference: http://tfl09.blogspot.cz/2010/08/using-newer-versions-of-net-with.html

4. Update schema

PS C:> Import-module AdmPwd.ps
PS C:> Update-AdmPwdSchema 

5. Remove “All Extended Rights” permission

This permission is not granted by default, you should however ensure it has not been granted manually as this would give access to the stored passwords.  

  • Use ADSIEDIT.msc to and connect to the “Default Naming Context”
  • Right-click the OU that will contain computer objects you want to manage,
  • Go to “Permissions” tab and click “Advanced”. 

You should also ensure that permission inheritance is enabled on sub-OUs.

6. Add Write permission to ms-MCS-AdmPwdExpirationTime and ms-MCS-AdmPwd attributes to SELF

PS C:> Set-AdmPwdComputerSelfPermission -OrgUnit

7. Add CONTROL_ACCESS permission to ms-MCS-AdmPwd attribute

In this step we grant permission to retrieve passwords from AD. See the previous post for more details. Firstly you need to create a group which you will use to grant access to retrieve passwords.

PS C:> Set-AdmPwdReadPasswordPermission -OrgUnit -AllowedPrincipals

8. Add Write permission to ms-MCS-AdmPwdExpirationTime attribute

In this step we grant permission to force password reset . 

PS C:> Set-AdmPwdResetPasswordPermission -OrgUnit -AllowedPrincipals

9. Create a GPO that will be used to enable password management

The GPO needs to be linked to the OU containing accounts of the computers you want to manager. You don’t configure any settings in the GPO. The magic happens in the next step. 

10. Register the CSE with the GPO

PS C:>  Register-AdmPwdWithGPO -GpoIdentity:

The cmdlet accepts displayName, GUID or DN.

This is all configuration that's required server side.

Now we need to deploy the CSE to computers we want to manage, and configure password requirements (see the previous post for and the documentation for details). 

Managing The Local Administrator Password - Part 2 - The Solution

Jiri Formacek, a Microsoft Services consultant (based on his LinkedIn profile), has published an excellent local admin password management solution. 

The solution uses Group Policy Client Side Extension (CSE) to set random and unique per computer local administrator password that is changed at a user controlled interval (30 days by default). The password is then stored in a confidential Active Directory (AD) attribute. Permission to retrieve the password is controlled using a security group.

The solution is described in the documentation so I won’t be repeating what’s there. I’ll go over the main points and some stuff that’s not covered in the official documentation.  I recommend reading the documentation.

The solution can be downloaded here:

http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789

The documentation can be found here:

http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789/file/96116/1/Documentation.zip

Implementation requires AD schema extension in order to create two new attributes and add them to the computer object class.  

The two attributes are:

  • ms-MCS-AdmPwd – stores the password 
  • ms-MCS-AdmPwdExpirationTime – stores the expiration time, password change can be forced by setting the value to “0”



The attributes are marked as confidential so the authenticated users group cannot read the values.
More on confidential attributes here:  http://support.microsoft.com/kb/922836

Access to the attributes is controlled, with a security group. I used two separate groups. One group with read access to the ms-MCS-AdmPwd attribute for retrieving the passwords and the second one with write permission to the ms-MCS-AdmPwdExpirationTime attribute allowing for forcing the reset. In most cases it would be the same group performing both, however I prefer to have an option of separating the tasks. Permission can be granted per OU so you can further subdivide the access. For example based on geographical location.

The passwords can be retrieved using “AD Users and Computers” and ADSIEDIT consoles. Also, the author provided a GUI tool that can be used to easily retrieve admin passwords. The tool is installed along with the management tools.


The Client Side Extension (CSE) is a DLL file that needs to be deployed to and registered on managed computers. A convenient MSI file is provided. It can be deployed using your standard package management tools such as SCCM, Altiris or Group Policy.

The management tools (Group Policy Template, PowerShell scripts, and the GUI tool) are installed using the same MSI. Only the CSE needs to be installed on the managed computers.


The CSE is configured using the provided GPO template. 


 The documentation states that the default password length is 15 characters, in fact it is 12. We definitely want to use at least 15 characters long password as this prevents Windows from storing passwords using insecure LM Hash. More on LanManager here: 


There are two settings in the template:




The CSE has an event log provider that logs to the Application Log. This is detailed in the documentation. I found it useful to set the logging level to the highest during testing.



Summarizing, I find this solution to meet all requirements. I have tested it on a 2012 AD with Win 7 clients and 2012 member servers as well as 2008R2 AD with Win7 and XP clients. I think this is an excellent solution.

A potential concern one may have is that the passwords are stored in clear text in AD directory partition. However, an attacker would have to obtain a copy of the AD database and extract the passwords offline. 

Managing The Local Administrator Password - Part 1 - The Issue

Local administrator password has always been a cause of a headache for security professionals. There hasn’t been a good and free way to manage the password on a large scale and most organizations ended up using the same password on all desktops or even servers. This introduces a number of vulnerabilities, such as:

  • All IT Staff know the password
  • The password is never changed
  • The password inevitably becomes known to the users and various 3rd parties
  • Machines are exposed to pass-the-hash attacks 

If an attacker, a malware or an evil insider gains access to a single machine currently logged on under the local admin account they will be able to access all machines by executing a script or using built-in management tools. Moreover, compromise of a single machine will allow an attacker to grab a password hash and use it to access other computers.

The local administrator password can be managed using Group Policy Preferences as detailed in the following article: 


While this satisfies most compliance requirements (they generally only require that passwords are changed at a set interval), this still leaves all computers with a single password. Furthermore, Group Policy Preferences store encrypted passwords in the SYSVOL folder and the encryption key is published on MSDN:


Clear text passwords can be retrieved from Group Policy Preferences using a PowerShell script as detailed in the article below:


Summarizing, GPO Preference is not a good solution.

As to other solutions, there is one from SANS. I haven’t explored it but it does look comprehensive:


OCSP response unauthorized or unsuccessful

Windows OCSP client requires that the OCSP responder URL is populated in the AIA extension. If it is not included, Windows will not form the OCSP request properly and the validation will fail with Certutil status of "Unsuccessful". The same certificate was successfully validated by a Cisco ASA OCSP client. 

According to the RFC2560 Apendix A.1.1:


{url} may be derived from the value of AuthorityInfoAccess or
   other local configuration of the OCSP client.

This does not seem to be the case in Microsoft's implementation. 

OCSP responder address is specified in the Authority Information Access (AIA) extension. In Windows CA, this is configured in the properties of the CA on the"Extensions" tab.




 Once configured all newly issued certificates will include the OCSP responder address.



Without the OCSP extension validation using certutil fails.



According to RFC2560, an OCSP request must specify hashing algorithm, issuer name hash, issuer key hash and serial number of the certificate to be validated. 

Extract from RFC2560:

CertID          ::=     SEQUENCE {
  hashAlgorithm       AlgorithmIdentifier,
  issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
  issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
  serialNumber        CertificateSerialNumber }

issuerNameHash is the hash of the Issuer's distinguished name. The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked. IsuerKeyHash is the hash of the Issuer's public key. The hash shall be calculated over the value(excluding tag and length) of the subject public key field in the issuer's certificate. The hash algorithm used for both these hashes, is identified in hashAlgorithm. serialNumber is the serial number of the certificate for which status is being requested.
If the AIA extension doesn't specify the OCSP URL Windows client does not include issuer's key hash in the request. 


In this case the responder returns an error of "unauthorized" and the validation fails. 


Extract from RFC2560:

2.3 Exception Cases

In case of errors, the OCSP Responder may return an error message. These messages are not signed. Errors can be of the following types:

   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized
The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server.

x.509 Certificates - Critical vs non-critical extensions

Extensions are used to associate additional information with the user or the key. 

Each certificate extension has three attributes - extnID, critical, extnValue

extnID - Extension ID - an OID that specifies the format and definitions of the extension
critical - Critical flag - Boolean value
extnValue - Extension value 

Criticality flag specifies whether the information in an extension is important. If an application doesn't recognize the extension marked as critical, the certificate cannot be accepted. If an extension is not marked as critical (critical value False) it can be ignored by an application.

In Windows, critical extensions are marked with a yellow exclamation mark, 






View certificate extensions using OpenSSL:

# openssl x509 -inform pem -in cert.pem -text -noout

(output abbreviated)

        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Subject Key Identifier:
                A1:96:A8:0E:32:4B:F6:BE:23:33:42:46:55:8A:72:64



Extract from RFC  "Internet X.509 Public Key Infrastructure - Certificate and CRL Profile" 

http://www.ietf.org/rfc/rfc2459.txt


4.1  Basic Certificate Fields


   The X.509 v3 certificate basic syntax is as follows.  For signature
   calculation, the certificate is encoded using the ASN.1 distinguished
   encoding rules (DER) [X.208].  ASN.1 DER encoding is a tag, length,
   value encoding system for each element.

 Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 encoded structure is the value of
   the octet string extnValue

  Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING  }


4.2  Standard Certificate Extensions

   The extensions defined for X.509 v3 certificates provide methods for
   associating additional attributes with users or public keys and for
   managing the certification hierarchy.  The X.509 v3 certificate
   format also allows communities to define private extensions to carry
   information unique to those communities.  Each extension in a
   certificate may be designated as critical or non-critical.  A
   certificate using system MUST reject the certificate if it encounters
   a critical extension it does not recognize; however, a non-critical
   extension may be ignored if it is not recognized.



Windows CRL caching

By default, both downloaded CRLs and OCSP responses are cached by a Windows client. If a
time-valid version of the CRL or OCSP response exists in the cache, the client will use the
cached version rather than downloading an updated CRL or submitting a new OCSP request. 

Caching related configuration is defined in the following registry hive:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config

A binary value of: 

ChainCacheResyncFiletime 

defines when cache will be cleared. 

Force the cache to be cleared:

c:\> certutil –setreg chain\ChainCacheResyncFiletime @now

Force the cache to clear in 1 hour:


c:\> certutil –setreg chain\ChainCacheResyncFiletime @now+0:1

View current cache life time config:

c:\> certutil –getreg chain\ChainCacheResyncFiletime

SCEP certificate enrollment - packet analysis


1. CA cert request:

Enrolling device requests and installs CA cert.

SCEP Opertion: GetCACert

HTTP Header:

GET /CertSrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=SCEPLab HTTP/1.0
Host: 10.0.0.6



2. SCEP server returns the CA cert:

In the case of GET operation with a type of GetCACert, the MIME content type returned will 
depend on whether or not an RA is in use. If there is no RA, only the CA certificate is sent back in the response, and the response has the content type tagged as application/x-x509-ca-cert.
If there is an RA, as it is the case in this lab, the RA certificates are sent back together with the CA certificates. The content type is application/x-x509-ca-ra-cert.


HTTP Header:

HTTP/1.1 200 OK
Content-Length: 4170
Content-Type: application/x-x509-ca-ra-cert
Server: Microsoft-IIS/8.0
Date: Mon, 29 Apr 2013 09:15:51 GMT
Connection: close



3. Device requests an identity certificate:

SCEP Operation: PKIOperation

HTTP Header (message string has been truncated):

GET /CertSrv/mscep/mscep.dll/pkiclient.exe?operation=PKIOperation&message=MIITnyeD%0%3D%3D%0A HTTP/1.0
Host: 10.0.0.6



4. SCEP server returns identity cert:

For each GET operation, the CA/RA server will return a MIME object via HTTP. For a GET operation with PKIOperation as its type, the response is tagged as having a Content Type of application/x-pki-message. The body of this message is a BER encoded binary PKI message.

HTTP Header:

HTTP/1.1 200 OK
Content-Length: 2067
Content-Type: application/x-pki-message
Server: Microsoft-IIS/8.0
Date: Mon, 29 Apr 2013 10:46:51 GMT
Connection: close



SCEP Reference: http://www.cisco.com/warp/public/cc/pd/sqsw/tech/scep_wp.htm

Enrolling Cisco ASA for certificates via SCEP


1. Install CA cert

ciscoasa(config)# crypto ca trustpoint CA
ciscoasa(config-ca-trustpoint)# revocation-check crl
ciscoasa(config-ca-trustpoint)# enrollment url http://10.0.0.6/certsrv/mscep/mscep.dll
ciscoasa(config)# crypto ca authenticate CA 

Debug output:


CRYPTO_PKI: HTTP response header:
HTTP/1.1 200 OK
Content-Length: 4170
Content-Type: application/x-x509-ca-ra-cert
Server: Microsoft-IIS/8.0
Date: Mon, 29 Apr 2013 11:13:14 GMT
Connection: close

Content-Type indicates we have received CA and RA certificates.

CRYPTO_PKI:crypto_process_ca_ra_cert(trustpoint=CA)

INFO: Certificate has the following attributes:

Fingerprint:     537adc87 22cc6e2b 07fdf2e0 18d8ba8b
The PKCS #7 message contains 4 certificates.

CRYPTO_PKI:crypto_pkcs7_extract_ca_cert found cert
CRYPTO_PKI: transaction GetCACert completed
CRYPTO_PKI: CA certificate received.
CRYPTO_PKI: crypto_pki_authenticate_tp_cert()
CRYPTO_PKI: trustpoint CA authentication status = 0
Trustpoint 'CA' is a subordinate CA and holds a non self-signed certificate.
Trustpoint CA certificate accepted.
CRYPTO_PKI: Verifying certificate with serial number: 4D00000002924DEC093140270B000000000002, subject name: cn=IssuingCA-DC1,dc=kp,dc=local, issuer_name: cn=ORCA1-CA, signature alg: SHA1/RSA.


2. Request and install identity certificate:

Depending on SCEP server configuration, a challenge password may be required to obtain certificate  In Microsoft's SCEP implementation - NDES - we browse to 
http://scepserver /CertSrv/mscep_admin to obtain the password


ASA config:


ciscoasa(config)# crypto ca trustpoint CA
ciscoasa(config-ca-trustpoint)# keypair testKey
ciscoasa(config-ca-trustpoint)#password C972703054ED1301
ciscoasa(config)# crypto ca enroll CA


% Start certificate enrollment ..
% The fully-qualified domain name in the certificate will be: ciscoasa.kp.local
% Include the device serial number in the subject name? [yes/no]: yes
% The serial number in the certificate will be: 123456789AB
Request certificate from CA? [yes/no]: yes


Debug output:


CRYPTO_PKI: Found a subject match - inserting the following cert record into certList
CRYPTO_PKI: Found a subject match - inserting the following cert record into certList
CRYPTO_PKI: Found a subject match - inserting the following cert record into certListThe certificate has been granted by CA!


Linux certificate storage


As opposed to Windows, Linux doesn't have crypto APIs that would be usable by user-mode applications. Linux does have Kernel level CryptoAPI (crypto.h) which is accessible to kernel mode processes. As such applications store certificates in application specific locations. That way we end up with multiple copies of the same certificate. One way to workaroud is to designate a directory for certificate storage and create symbolic links in required directories. 

The Linux Kernel Cryptographic API overview: https://thesweeheng.files.wordpress.com/2007/11/6451.pdf


Generate CSR using a new key pair:

openssl req -nodes -newkey rsa:1024 -keyout serverName.key -out serverName.csr

Generate CSR using an existing key pair:

openssl req -new -key serverName.key -out serverName.csr


Once the request is signed, certs and keypair must be copied to relevant location. Most Linux applications require Base64 encoded certificate with .PEM extension. This however may vary. Apache for example requires Base64 encoded .CRT certificate. 

Sample storage locations:

Cisco AnyConnect:

User certs:

~/.cisco/certificates/ca                  Root CA
~/.cisco/certificates/client               User certificate 
~/.cisco/certificates/client/private       PrivateKeys


Computer certs:

/opt/.cisco/certificates/ca                    Root CA
/opt/.cisco/certificates/client                Client certificates 
/opt/.cisco/certificates/client/private    PrivateKeys


Nessus:

/opt/nessus/com/nessus/CA/servercert.pem 
/opt/nessus/var/nessus/CA/serverkey.pem


Apache:

Locations of cert and private key are specified in the config file (sample config below) per virtual host. Sample location:

/etc/httpd/conf/ssl.crt/serverName.crt
/etc/httpd/conf/ssl.key/serverName.key

Enabling SSL in Apache. 

Enable mod_ssl:

# e2enmod ssl

Configure Virtual Host:

This is configured in an httpd.conf or apache2.conf (which by default includes httpd.conf)


DocumentRoot /var/www/
ServerName 10.0.0.20
SSLEngine on
SSLCertificateFile /etc/apache2/conf/ssl.crt/10.0.0.20.crt
SSLCertificateKeyFile /etc/apache2/conf/ssl.key/10.0.0.20.key


Restart  service:

# service httpd restart

or

# apachectl -restart

OCSP certificate validation - packet analysis

Online Certificate Status Protocol (OCSP) is an IETF standard defined in RFC 2560 (http://www.ietf.org/rfc/rfc2560.txt). OCSP is used for real-time certificate status checking. OCSP uses HTTP as its transport mechanism. Transaction consists of an HTTP query using an HTTP POST verb and an HTTP 200 response. 

1. OCSP request (MIME type: ocsp-request):

HTTP header:

POST /ocsp HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: application/ocsp-request
Accept: */*
User-Agent: Microsoft-CryptoAPI/6.2
Content-Length: 86
Host: srv3.kp.local

The request contains hash of the issuer's name and public key along with the serial number of the certificate to be validated:



2. OCSP response (MIME type: ocsp-response): 

HTTP header:

HTTP/1.1 200 OK

Cache-Control: max-age=580
Content-Length: 1256
Content-Type: application/ocsp-response
Expires: Mon, 22 Apr 2013 10:34:16 GMT
Last-Modified
: Mon, 22 Apr 2013 08:59:16 GMT

ETag: "407c5206fbf20cfa69f6110435a82fd4"
Server: Microsoft-IIS/8.0
Date: Mon, 22 Apr 2013 09:59:35 GMT


OCSP response contains the revocation status 


To prevent spoofing attacks, the response is signed by the responder. In order to validate the signature, certificate containing public key of the responder is returned. This could lead to a problem whereby OCSP signing certificate revocation would be checked leading to a "verification loop". According to the RFC's 2560 section 4.2.2.2.1 there are three ways of overcoming this issue. Microsoft CA implementation uses special extension "id-pkix-ocsp-nochek". This extention tells the requester not to validate status of the OCSP signing certificate. The risk of the certificate being misused is mitigated by using very short certificate validity periods. 


OCSP signing certificate:



Corresponding OCSP responder signing configuration:



CRL request over HTTP - packet analysis

One of the ways a CRL can be retrieved is HTTP. Whole transaction consists of an HTTP GET and an OK 200 response packets. The response is a PKIX-CRL MIME type encoded CRL. PKIX-CRL is an IETF standard defined in RFC 2585 http://www.ietf.org/rfc/rfc2585.txt

1. CRL requester generates an HTTP query using an HTTP GET verb

HTTP header:

GET /pki/IssuingCA-DC1.crl HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
User-Agent: Microsoft-CryptoAPI/6.2
Host: dc1.kp.local



2. Server responds with CRL encoded in PKIX-CRL MIME type

HTTP header:

HTTP/1.1 200 OK
Content-Type: application/pkix-crl
Last-Modified: Mon, 22 Apr 2013 08:29:51 GMT
Accept-Ranges: bytes
ETag: "d06e258f333fce1:0"
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Date: Sun, 21 Apr 2013 08:46:23 GMT
Content-Length: 820




WireShark decodes the PKIX-CRL. We can see all CRL extensions directly in the packet.

Cisco ASA Certificate Revocation Checking


ASA supports status verification using CRLs and OCSP. CRL can be retrieved using HTTP, LDAP or SCEP.

Revocation checking using CRL:

Over HTTP:

ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2
ciscoasa(config-ca-trustpoint)# revocation-check crl
ciscoasa(config-ca-crl)# protocol http

By default ASA will use address listed in CDP extension of the certificate that is being validated. To override default behaviour we need to add the following in the CRL configuration context.

ciscoasa(config-ca-crl)# policy static
ciscoasa(config-ca-crl)# url 1 http://cdpurl.kp.local/crl.crl


Over LDAP:

Certificate I'm using for this lab, doesn't have LDAP address in its CDP extension. Therefore I'm using "policy static"  to specify LDAP URL where CRL can be retrieved. 

ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2
ciscoasa(config-ca-trustpoint)# revocation-check crl
ciscoasa(config-ca-trustpoint)# crl configure
ciscoasa(config-ca-crl)# protocol ldap
ciscoasa(config-ca-crl)# policy static

ciscoasa(config-ca-crl)# url 1 ldap://dc1.kp.local/CN=IssuingCA-DC1,CN=dc1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=kp,DC=local/

ciscoasa(config-ca-crl)# ldap-dn CN=asacrl,OU=UsersRoot,DC=kp,DC=local password

ciscoasa(config-ca-crl)# ldap-defaults 10.0.0.7


Revocation checking using OCSP:

ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2
ciscoasa(config-ca-trustpoint)# revocation-check ocsp
ciscoasa(config-ca-trustpoint)# ocsp url http://srv3.kp.local/ocsp


View CRL cache:


ciscoasa# show crypto ca crl

CRL Issuer Name:
    cn=IssuingCA-DC1,dc=kp,dc=local
    LastUpdate: 15:23:47 UTC Apr 11 2013
    NextUpdate: 03:43:47 UTC Apr 19 2013
    Cached Until: 14:54:45 UTC Apr 15 2013
    Retrieved from CRL Distribution Point:
      http://dc1.kp.local/pki/IssuingCA-DC1.crl
    Size (bytes): 716
    Associated Trustpoints: ASDM_TrustPoint0


Enable crypto transaction debugging:

ciscoasa# debug crypto ca transactions 10


Retrieve CRL: 


ciscoasa(config)#crypto ca crl request ASDM_TrustPoint0

CRYPTO_PKI: CRL is being polled from CDP http://dc1.kp.local/pki/IssuingCA-DC1.crl.

CRYPTO_PKI: HTTP response header:
 HTTP/1.1 200 OK
Content-Type: application/pkix-crl
Last-Modified: Thu, 11 Apr 2013 15:33:47 GMT
Accept-Ranges: bytes
ETag: "edeaef5c936ce1:0"
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Date: Mon, 15 Apr 2013 13:50:57 GMT
Connection: close
Content-Length: 716

CRYPTO_PKI: Found a subject match - inserting the following cert record into certList
CRYPTO_PKI: set CRL update timer with delay: 309171
CRYPTO_PKI: the current device time: 13:50:56 UTC Apr 15 2013

CRYPTO_PKI: the last CRL update time: 15:23:47 UTC Apr 11 2013
CRYPTO_PKI: the next CRL update time: 03:43:47 UTC Apr 19 2013
CRYPTO_PKI: CRL cache delay being set to: 3600000
CRYPTO_PKI: transaction HTTPGetCRL completed


Debug output of certificate validation using CRL:

CRYPTO_PKI: Verifying certificate with serial number: 4D00000002924DEC093140270B000000000002, subject name: cn=IssuingCA-DC1,dc=kp,dc=local, issuer_name: cn=ORCA1-CA, signature alg: SHA1/RSA.

CRYPTO_PKI(Cert Lookup) issuer="cn=ORCA1-CA" serial number=4d 00 00 00 02 92 4d ec 09 31 40 27 0b 00 00 00    
CRYPTO_PKI: Cerificate is resident.
CRYPTO_PKI: Verify chain of certs, Getting public key from signersCert.
CRYPTO_PKI: Sorted chain size is: 1
CRYPTO_PKI: Found ID cert. serial number: 6D000000075A2D9B4FE8E34DF7000000000007, subject name: ea=jd@kp.local,cn=Joe Doe
CRYPTO_PKI: Verifying certificate with serial number: 6D000000075A2D9B4FE8E34DF7000000000007, subject name: ea=jd@kp.local,cn=Joe Doe, issuer_name: cn=IssuingCA-DC1,dc=kp,dc=local, signature alg: SHA1/RSA.
CRYPTO_PKI(Cert Lookup) issuer="cn=IssuingCA-DC1,dc=kp,dc=local" serial number=6d 00 00 00 07 5a 2d 9b 4f e8 e3 4d f7 00 00 00                                   |  ...

CRYPTO_PKI: Starting CRL revocation check.
CRYPTO_PKI: Attempting to find cached CRL for CDP http://dc1.kp.local/pki/IssuingCA-DC1.crl
CRYPTO_PKI: Found CRL in cache for CDP: http://dc1.kp.local/pki/IssuingCA-DC1.crl, status 0.
CRYPTO_PKI: Certificate is revoked!


Debug output of certificate validation using OCSP:


CRYPTO_PKI: Sorted chain size is: 2
CRYPTO_PKI: Verifying certificate with serial number: 4D00000002924DEC093140270B000000000002, subject name: cn=IssuingCA-DC1,dc=kp,dc=local, issuer_name: cn=ORCA1-CA, signature alg: SHA1/RSA.
CRYPTO_PKI(Cert Lookup) issuer="cn=ORCA1-CA" serial number=4d 00 00 00 02 92 4d ec 09 31 40 27 0b 00 00 00   
CRYPTO_PKI: Cerificate is resident.

CRYPTO_PKI: Verify chain of certs, Getting public key from signersCert.

CRYPTO_PKI: Sorted chain size is: 1
CRYPTO_PKI: Found ID cert. serial number: 6D000000075A2D9B4FE8E34DF7000000000007, subject name: ea=jd@kp.local,cn=Joe Doe
CRYPTO_PKI: Verifying certificate with serial number: 6D000000075A2D9B4FE8E34DF7000000000007, subject name: ea=jd@kp.local,cn=Joe Doe, issuer_name: cn=IssuingCA-C1,dc=kp,dc=local, signature alg: SHA1/RSA.

CRYPTO_PKI(Cert Lookup) issuer="cn=IssuingCA-DC1,dc=kp,dc=local" serial number=6d00 00 00 07 5a 2d 9b 4f e8 e3 4d f7 00 00 00
CRYPTO_PKI: Verify cert is polling for revocation status.

CRYPTO_PKI: Starting OCSP revocation
CRYPTO_PKI: no responder matching this URL; create one!
CRYPTO_PKI: http connection opened
CRYPTO_PKI: OCSP response status - unauthorized.
CRYPTO_PKI: transaction GetOCSP completed

Managing Certificate Revocation Lists (CRLs) in Windows


Publish CRL to LDAP store:

C:\> certutil -dspublish .\IssuingCA-DC1.crl serverName

Validate certificate's Authority Information Access (AIA), Certificate Revocation List (CRL), Online Certificate Status Protocol (OCSP) status:

C:\>certutil -URL certname.cer

This command launches below UI that can be used to check the following:

Note: the certificate in question is revoked

Authority Information Access (AIA) - this extension specify location where CA certificates are located ( used for building certification path):




CRL accessibility based on CRL Distribution Point (CDP) extension:




Revocation status using OCSP:


OCSP URL is specified in AIA extension:


Download CRL (creates file "Blob0_1_0.crl" in working directory):

C:\> certutil-split  -URL http://dc1.kp.local/pki/IssuingCA-DC1.crl

View CRL publication related registry entries:

C:\> certutil -getreg ca\CRLPublicationURLs

Verify revocation and validity of a specific certificate:

C:\> certutil -f -urlfetch -verify .\compcert.cer


View CRL cached by CryptoAPI:

Windows CryptoAPI caches CRL for performance reasons.

C:\> certutil -urlcache CRL

Update local CRL cache / View CRL:

Command below forces update of CRL cache.