Files on ASA when ASA is a CA (located in LOCAL-CA-SERVER folder):
LOCAL-CA-SERVER.ser is a clear-text file containing the serial number of issued certificates.
LOCAL-CA-SERVER.cdb is clear-text file containing information about issued certificates.
LOCAL-CA-SERVER.udb is a clear-text file containing information about enrolled users.
LOCAL-CA-SERVER.crl is a password-encrypted file containing information about revoked certificates.
LOCAL-CA-SERVER.p12 is a password-encrypted file containing the RSA public/private key pair and the self-signed certificate.
If you need to delete file form ASA flash:
delete /recursive /noconfirm flash:/LOCAL-CA-SERVER.
ASA04-5520(config)# crypto ca server
ASA04-5520(config-ca-server)# keysize 2048
ASA04-5520(config-ca-server)# keysize server 2048
ASA04-5520(config)# domain-name cciesecblog.com
ASA04-5520(config-ca-server)# smtp from-address ASA4@cciesecblog.com
ASA04-5520(config-ca-server)# smtp subject Use this URL to enroll with INE CA
ASA04-5520(config-ca-server)# lifetime certificate 730
ASA04-5520(config-ca-server)# publish-crl VLAN27 443
ASA04-5520(config-ca-server)# no shut
% Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or press return to exit
% Passphrase must be more than 7 characters. Try again
% or press Return to exit
Passphrase: **********
Re-enter passphrase: **********
Keypair generation process begin. Please wait…
Completed generation of the certificate and keypair…
Archiving certificate and keypair to storage… Complete
INFO:
Certificate Server enabled.
ASA04-5520(config)# webvpn
ASA04-5520(config-webvpn)# enable vlAN27
ASA04-5520(config)# crypto ca server user-db add RTR01 email rtr01@cciesecblog.com dn CN=rtr01
ASA04-5520(config)# crypto ca server user-db add RTR02 email rtr02@cciesecblog.com dn CN=rtr02
ASA04-5520(config)# crypto ca server user-db allow user rtr01
ASA04-5520(config)# crypto ca server user-db allow user rtr02
ASA04-5520(config)# sh crypto ca server
Certificate Server LOCAL-CA-SERVER:
Status: enabled
State: enabled
Server’s configuration is locked (enter “shutdown” to unlock it)
Issuer name: CN=ASA04-5520
CA certificate fingerprint/thumbprint: (MD5)
2bc755ad 00c06f8c 741c1fb8 2556eb97
CA certificate fingerprint/thumbprint: (SHA1)
564f7919 cf0bf615 cfe8813d cf153468 1787fdb4
Last certificate issued serial number: 0x1
CA certificate expiration timer: 15:03:17 UTC Aug 19 2016
CRL NextUpdate timer: 21:03:17 UTC Aug 20 2014
Current primary storage dir: flash:/LOCAL-CA-SERVER/
Auto-Rollover configured, overlap period 30 days
Autorollover timer: 15:03:17 UTC Jul 20 2016
WARNING: Configuration has been modified and needs to be saved!!
ASA04-5520(config)#
ASA04-5520(config)# sh asp table socket
Protocol Socket Local Address Foreign Address State
TCP 000034bf 136.1.27.8:443 0.0.0.0:* LISTEN
DTLS 0000636f 136.1.27.8:443 0.0.0.0:* LISTEN
ASA04-5520(config)#
ASA04-5520(config)# show crypto ca server user-db username rtr01
username: rtr01
email: rtr01@cciesecblog.com
dn: CN=RTR01
allowed: 15:06:24 UTC Sat Aug 23 2014
notified: 1 times
enrollment status: Allowed to Enroll
ASA04-5520(config)#
ASA04-5520(config)# show crypto ca server user-db
username: rtr01
email: rtr01@cciesecblog.com
dn: CN=RTR01
allowed: 15:06:24 UTC Sat Aug 23 2014
notified: 1 times
enrollment status: Allowed to Enroll
username: rtr02
email: rtr02@cciesecblog.com
dn: CN=RTR02
allowed: 15:06:26 UTC Sat Aug 23 2014
notified: 1 times
enrollment status: Allowed to Enroll
AASA04-5520(config)# sh crypto ca server
Certificate Server LOCAL-CA-SERVER:
Status: enabled
State: enabled
Server’s configuration is locked (enter “shutdown” to unlock it)
Issuer name: CN=ASA04-5520
CA certificate fingerprint/thumbprint: (MD5)
2bc755ad 00c06f8c 741c1fb8 2556eb97
CA certificate fingerprint/thumbprint: (SHA1)
564f7919 cf0bf615 cfe8813d cf153468 1787fdb4
Last certificate issued serial number: 0x1
CA certificate expiration timer: 15:03:17 UTC Aug 19 2016
CRL NextUpdate timer: 21:03:17 UTC Aug 20 2014
Current primary storage dir: flash:/LOCAL-CA-SERVER/
Auto-Rollover configured, overlap period 30 days
Autorollover timer: 15:03:17 UTC Jul 20 2016
WARNING: Configuration has been modified and needs to be saved!!
ASA04-5520(config)# crypto ca server user-db show-otp user rtr01
Username: rtr01
OTP: 9C14982D1F48AA76
Enrollment Allowed Until: 15:06:24 UTC Sat Aug 23 2014
PKI (Public Key Infrastructure) is system managing the public key cryptography also known as asymmetric cryptography. PKI uses set of protocols, standards, services and policies to achieve this goal. PKI uses a pair of two keys mathematically matched. One is used for encryption process another is used for decryption process. These are private and public keys. Private key is know only to its owner and public key is publicly available.
Symmetric cryptography uses single key for both encryption and decryption process.
Confidentiality. A message encrypted with a public key can only be decrypted by its corresponding private key, which is known only to its owner, thus ensuring that the message can be read/decrypted only by the private-key owner for which the message was generated.
Authentication/integrity. A message encrypted with a private key can only be decrypted by its corresponding public key; anyone can get the public-key and thus read/decrypt the message, but because the private-key resides only with the owner, it guarantees identity of the message source. This process ensures authenticity and non-repudiation of the message (also known as digital signature); if combined with a hash function, it can also provide message integrity.
How to ensure that I receive a public key from a trusted sources? The role of a Certificate Authority (CA) exists to create the necessary trust level between two peers through the use of identities, also called digital certificates.
The following is a simplified step-by-step guide for issuing digital certificates through the CA:
1 – The CA generates its own pair of RSA/EC public/private keys, issues a self-signed digital certificate, and becomes a CA (the private key of the CA should be safeguarded and never be shared with others).
2 – Each client requiring a digital certificate generates its own pair of public/private RSA/EC keys.
3 – The public key of the client, along with other information required to prove its identity, is submitted to the CA in the form of a Certificate Signing Request (the request is signed with the client private key so that the CA can verify the authenticity of the request).
4 – The CA provides a digital signature to the submitted information using its own private key, and the result is a digital certificate.
5 – The resulting digital certificate is issued back to the requesting client.
A digital certificate (aka public key certificate) is like a passport containing information (similar to a personal identification number) that uniquely identifies you; to be recognized as valid, it also requires the signature of the issuer (the CA). To be universally valid, it needs a certain format or structure and a minimum amount of information, which is described in X.509 standard. At a minimum, it must make use of the following:
Version – Based on the version and the certificate template being used, the certificate is valid for certain purposes (for example, it can be used for encryption but not for digital signature).
Serial Number – Uniquely identifies a certificate issued by a CA.
Issuer – Information about the CA, such as Common Name or FQDN.
Validity – The start/end time for which the certificate is valid and can be used.
Subject – Information about the client, such as Common Name or FQDN.
Public Key – The client’s public key data and algorithm.
Certificate Signature – The CA signature data and algorithm.
When two peers need to perform authentication using digital certificates (such as in SSL or IPsec VPNs), the following is required:
– Both peers exchange their certificates, which need to be valid at that time.
– Certificates can be issued by different certificate authorities.
– For one peer to verify the identity from the presented certificate of the remote peer, it must read the digital signature from the certificate, so it needs the know and trust the public key of the issuing certificate authority.
The Certificate Signing Request (CSR) required to obtain an X.509 digital certificate also uses a standard format. At a minimum, the CSR contains the public key and one or more of the following fields, which will appear in the Subject field of the certificate:
Common Name or Distinguished Name (FQDN)
Organizational Unit and Organization
Town and Country
E-mail Address
In general, a CSR can be generated and submitted using Active Directory Certificate Services (ADCS), Simple Certificate Enrollment Protocol/ Network Device Enrollment Service (SCEP/NDES), Web enrollment, and Manual (terminal-based) enrollment. When the CA issues/approves the certificate, it must be installed/imported by the requesting client.
Some standard certificate file formats are:
PEM (Privacy Enhanced Mail) == A base64 encoded file containing one or more digital certificates along with associated private keys, optionally protected by a password.
Base64 == A binary format file containing a single certificate, without support for certificate chain or private keys
P7B/PKCS#7 (Cryptographic Message Syntax Standard) == A base64 encoded file containing one or more certificates and all CA certificates in the certification chain, without support for the private keys of the certificates.
DER (Distinguished Encoding Rules) == A binary format file containing a single certificate, without support for certificate chain or private keys.
PFX/PKCS#12 (Personal Information Exchange) == A binary format file containing one or more digital certificates along with associated private keys and all CA certificates in the certification chain, optionally protected by a password.
The digital certificate provides only the public information, but for it to be usable by its owner, it needs the associated private key. For this reason, if you want to export a certificate for backup purposes and make it usable on import, you must use the PEM or PKCS#12 formats.
A digital certificate can be revoked at any time, such as when compromised or no longer used by its owner. For this reason, when a trust relationship based on certificates is established, it may be desirable to first determine whether the received certificate of a remote peer is still valid. The only entity that can revoke a certificate (invalidate it before it expires according to its validity period) is the issuer, and this is the CA. There are two options for verifying a certificate:
The CA can publish a Certificate Revocation List (CRL), which contains the serial numbers of certificates in revoked or hold state. The CA refreshes this list periodically but not instantly, and any client can download and cache it for a period of time; this method of validating certificates is not 100% accurate because it does not happen in real time.
Using Online Certificate Status Protocol (OCSP). Each time a digital certificate is received, an OCSP query is sent to ask about its status based on the serial number; this method is 100% accurate because it is not based on a periodically refreshed list, but on a real-time query/response.
In large PKI deployments, you may experience performance issues caused by a high number of CSRs, or you may want to have multiple CAs geographically dispersed within the same PKI system. The components of a hierarchical PKI are:
Root CA. This is the first CA installed in your PKI deployment.
Highest level in a hierarchical PKI.
Can act as a fully functional CA (manage client certificate’s life cycle).
Has a self-signed digital certificate with the highest lifetime in the PKI.
Can delegate all the CA functions to subordinate CAs.
Can delegate part of its functions to RAs.
With Subordinate CA’s, the Root CA is taken offline for security reasons and is only responsible for issuing certificates to subordinate CAs.
Subordinate CA. This is the second CA installed in your PKI.
Second-highest level in a hierarchical PKI if subordinate to the root CA.
Can also be subordinate to another subordinate CA.
Can act as a fully functional CA (manage client certificate’s life cycle).
Has a digital certificate received from the root/subordinate CA with a high lifetime.
Can delegate all the CA functions to other subordinate CAs.
Can delegate part of its functions to RAs.
Registration Authority. This is an optional role in your PKI.
Acts as a proxy between clients and root/subordinate CA.
Its functions are performed by default by the root/subordinate CA.
Authenticates and authorizes client certificate requests.
Forwards valid and approved requests to the subordinate/root CA.
Cannot issue client certificates.
CCIE Security Blog 