#SecureSenses --verbose

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

The way IOS stores certificates depends on enrolment method.  Certificates enrolled via command line or SCEP are stored in config: R1#show run | begin crypto pki certificates crypto pki certificate chain ORCA1-CA  certificate ca 37A15821A55DD2864B62A67B6EFD5429   3082038A 30820272 A0030201 02021037 A15821A5 5DD2864B 62A67B6E FD542930 Certificates installed via SDM are stored in NVRAM: R2#dir nvram: Directory of nvram:/    45  -rw-      1629                        startup-config    46  ----        7636                       private-config     1  -rw-           4                        rf_cold_starts     2  -rw-           0                        ifIndex-table     3  -rw-         910                      ORCA1-CA#5429CA.cer     4  -rw-         571                      IOS-CA-R2OUK#7401CA.cer When the built-in IOS CA server is enabled, the CA cert is stored in NVRAM.

In this post we'll go over enrolling Cisco IOS routers for certificates using terminal.   Generate keys Firstly we need to generate key pair that we'll then use to create Certificate Signing Request (CSR) that will include our public key. Here we need to decide on the key length. Security wise - the longer the better. It's never that simple though. To this day there are applications that simply do not support anything longer than 2048. This should be taken into consideration. Do we need anything longer than that? We'd have to consider the threat vector. Longer key makes factorization harder. To my knowledge as of writing 1024 bit keys have not been factored. It would take very long time and a lot of very advanced infrastructure to do. This is not a valid threat for most organizations. Key length should be considered in terms of certificate lifetime. The longer the validity the longer they. There also is the CPU overhead we need to take into account. Yes, nowaday