#SecureSenses --verbose

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

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

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

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 H

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&

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 ex

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

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.

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

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 re

Privacy Enhanced Mail (PEM) format .cer / .pem      - Base-64 encoded ASCII files  - can be open  in a text editor - Can contain certificates and private keys Distinguished Encoding Rules (DER) format .cer  / .crt / .der - Binary encoded  - Hash of the file matches certificate's thumbprint - Susceptible to corruption due to binary format              (single bit change will invalidate cert as the hash won't match) Public Key Cryptography Standards (PKCS) Cryptographic Message Syntax Standard   - PKCS#7 .p7b / .p7c  - Binary encoded format - Can include whole certification path - Cannot contain private keys Personal Information Exchange - PKCS#12 .pfx / .p12 - Passphrase protected - Can contain private keys - Can include whole certification path References: https://www.sslshopper.com/ssl-converter.html http://technet.microsoft.com/en-us/library/cc738545(v=ws.10).aspx This is very low level Windows API stuff: http

This procedure is largely the same as in IOS. Generate Keys: ciscoasa(config)# crypto key generate rsa general-keys modulus 1024 INFO: The name for the keys will be: Keypair generation process begin. Please wait... Verify keys have been generated: ciscoasa(config)# show crypto key mypubkey rsa Key pair was generated at: 14:56:09 UTC Apr 5 2013 Key name:  Usage: General Purpose Key  Modulus Size (bits): 1024  Key Data:   30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00c0a355 Create trustpoint for root CA: ciscoasa(config)# crypto ca trustpoint ORCA1-CA ciscoasa(config-ca-trustpoint)# enrollment terminal ciscoasa(config)# crypto ca authenticate ORCA1-CA Enter the base 64 encoded CA certificate. End with the word "quit" on a line by itself -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- quit INFO: Certificate has the following attributes: Fingerprint:     e9fd8a22 e82c13ef 5db781a7 616ad113 Do you accept this certifica