About Certificates
Digital certificates provide digital identification for authentication. A digital certificate includes information that identifies a device or user, such as the name, serial number, company, department, or IP address. A digital certificate also includes a copy of the public key for the user or device. Certificates are used for SSL (Secure Socket Layer), TLS (Transport Layer Security), and DTLS (Datagram TLS) connections, such as HTTPS and LDAPS.
You can create the following types of certificate:
-
Internal certificates—Internal identity certificates are certificates for specific systems or hosts. You can generate these yourself using the OpenSSL toolkit or get them from a Certificate Authority. You can also generate a self-signed certificate.
-
Internal Certificate Authority (CA) certificates—Internal CA certificates are certificates that the system can use to sign other certificates. These certificates differ from internal identity certificates with respect to the basic constraints extension and the CA flag, which are enabled for CA certificates but disabled for identity certificates. You can generate these yourself using the OpenSSL toolkit or get them from a Certificate Authority. You can also generate a self-signed internal CA certificate. If you configure self-signed internal CA certificates, the CA runs on the device itself.
-
Trusted Certificate Authority (CA) certificates—A trusted CA certificate is used to sign other certificates. It is self-signed and called a root certificate. A certificate that is issued by another CA certificate is called a subordinate certificate.
Certificate Authorities (CAs) are trusted authorities that “sign” certificates to verify their authenticity, thereby guaranteeing the identity of the device or user. CAs issue digital certificates in the context of a PKI, which uses public-key or private-key encryption to ensure security. A CA can be a trusted third party, such as VeriSign, or a private (in-house) CA that you establish within your organization. CAs are responsible for managing certificate requests and issuing digital certificates. For more information, see Public Key Cryptography.
Public Key Cryptography
In public key cryptography, such as the RSA encryption system, each user has a key pair containing both a public and a private key. The keys act as complements, and anything encrypted with one of the keys can be decrypted with the other.
In simple terms, a signature is formed when data is encrypted with a private key. The signature is attached to the data and sent to the receiver. The receiver applies the public key of the sender to the data. If the signature sent with the data matches the result of applying the public key to the data, the validity of the message is established.
This process relies on the receiver having a copy of the public key of the sender and a high degree of certainty that this key belongs to the sender, not to someone pretending to be the sender.
Obtaining the public key of a sender is normally handled externally or through an operation performed at installation. For example, most web browsers are configured with the root certificates of several CAs by default.
You can learn more about digital certificates and public key cryptography through openssl.org, Wikipedia, or other sources. Having a firm understanding of SSL/TLS cryptography will help you establish secure connections to your device.
Certificate Types Used by Feature
You need to create the right type of certificate for each feature. The following features require certificates.
- Identity Policies (Captive Portal)—Internal Certificate
-
(Optional.) Captive portal is used in identity policies. Users must accept this certificate when authenticating to the device for purposes of identifying themselves and getting their IP address associated with their usernames. If you do not supply a certificate, the device uses an automatically generated certificate.
- Identity Realms (Identity Policies and Remote Access VPN)—Trusted CA Certificate
-
(Optional.) If you use an encrypted connection for your directory server, the certificate must be accepted to perform authentication with the directory server. Users must authenticate when prompted by identity and remote access VPN policies. A certificate is not needed if you do not use encryption for the directory server.
- Management Web Server (Management Access System Settings)—Internal Certificate
-
(Optional.) FDM is a web-based application, so it runs on a web server. You can upload a certificate that your browser accepts as valid to avoid getting an Untrusted Authority warning.
- Remote Access VPN—Internal Certificate
-
(Required.) The internal certificate is for the outside interface, which establishes the device identity for AnyConnect クライアントs when they make a connection to the device. Clients must accept this certificate.
- Site-to-Site VPN—Internal and Trusted CA Certificates
-
If you use certificate authentication for a site-to-site VPN connection, you need to select the internal identity certificate used to authenticate the local peer in the connection. Although it is not part of the VPN connection definition, you also need to upload the trusted CA certificates that were used to sign the local and remote peer identity certificates, so that the system can authenticate the peers.
- SSL Decryption Policy—Internal, Internal CA, and Trusted CA Certificates
-
(Required.) The SSL decryption policy uses certificates for the following purposes:
-
Internal certificates are used for known key decryption rules.
-
Internal CA certificates are used for decrypt re-sign rules when creating the session between the client and FTD device.
-
Trusted CA certificates are used indirectly for decrypt re-sign rules when creating the session between the FTD device and server. Trusted CA certificates are used to verify the signing authority of the server's certificate. Unlike the other certificates, you do not directly configure these certificates in the SSL decryption policy; they simply need to be uploaded to the system. The system includes a large number of trusted CA certificates, so you might not need to upload any additional certificates.
-
Example: Generating an Internal Certificate using OpenSSL
The following example uses OpenSSL commands to generate an internal server certificate. You can obtain OpenSSL from openssl.org. Consult OpenSSL documentation for specific information. The commands used in this example might change, and you might have other options available that you might want to use.
This procedure is meant to give you an idea of how to obtain a certificate to upload to FTD.
 （注） |
The OpenSSL commands shown here are examples only. Adjust the parameters to fit your security requirements. |
手順
| ステップ 1 |
Generate a key. |
| ステップ 2 |
Generate a certificate signing request (CSR). |
| ステップ 3 |
Generate a self-signed certificate with the key and CSR. Because the FDM does not support encrypted keys, try to skip the challenge password by just pressing return when generating a self signed certificate. |
| ステップ 4 |
Upload the files into the appropriate fields when creating an internal certificate object in the FDM. You can also copy/paste the file contents. The sample commands create the following files:
|
フィードバック