Certificates

A certificate is an electronic data structure used to identify an individual, a server, a company, or some other entity, and to associate that identity with a public key and an associated private key. Like a passport, a certificate provides generally recognized proof of an entity's identity. Certificates bind public key values to entities, so that remote users of an entity’s public key can be certain the associated private key is owned by the correct person or system. Certificates help prevent the use of fake public keys for impersonation. Only the public key certified by the certificate works with the corresponding private key possessed by the entity identified by the certificate. The most widely accepted format for certificates is defined by the ITU-T X.509 international standard, which is described in RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.

Certificate authorities (CAs) are entities that validate identities and issue certificates. An organization that wants to serve as its own CA can issue its own certificates, or an organization can purchase certificates from a trusted third-party CA. The methods used to validate an identity vary depending on the policies of a given CA. In general, before issuing a certificate, a CA must verify the identity of the entity and must digitally sign the certificate to ensure it cannot be modified. This ensures that a certificate issued by a CA binds a particular public key to the name of the entity the certificate identifies (such as the name of an employee).

In addition to a public key, a certificate includes the name of the entity it identifies, an expiration date, the name and URI of the CA that issued the certificate, a serial number, and the digital signature of the issuing CA, which creates a mathematical relationship between the signing CA certificate's public key and the public key of the certificate it signs. The CA's digital signature allows the certificate to function as a letter of introduction for users who know and trust the CA but do not know the entity identified by the certificate.

Because a certificate’s expiration date is part of its signed contents, remote entities can verify that a certificate is valid and current.

Common types of certificates include the following:

Certificate Authority certificates can sign other certificates.
Server certificates are used on a server to enable a software client to verify the validity of the connection to a machine and to create an encrypted channel between a client and a server.
Client certificates enable a server to verify a client’s identity (certificate-based authentication) and enable a user to digitally sign or encrypt data. Client certificates, which are digitally signed by a trusted certificate authority, are stronger proof of a client’s identity than username/password credentials alone.
Note
Digital Signature Algorithm (DSA) certificates are not supported.

Certificate Chains

A certificate chain is a sequence of certificates, where each certificate in the chain is signed by the certificate above it in the chain. At the top of the chain is a self-signed certificate. Each CA in the chain vouches for the identity in the entity to which it issues a signed digital certificate. Certificate chains establish a chain of trust; if you trust the CA at the top of the chain, this implies you can trust the signed certificates below it in the chain.

Certificate Revocation Lists

Under normal circumstances, a certificate remains valid until it reaches its expiration date. However, a certificate may become invalid before it expires. For example, if an employee whose identity is bound to a certificate terminates employment or if an enterprise suspects the confidentiality of the private key associated with a certificate’s public key has been compromised, the certificate might be declared invalid and revoked before its expiration date.

When a CA revokes a certificate, it must let other entities know the certificate is no longer valid and not to accept it. A certificate revocation list (CRL) is a signed data structure that identifies the serial numbers of certificates that have been issued and subsequently revoked by the CA. When a remote entity is asked to use a certificate to verify a remote user’s identity, it can download a current copy of the applicable CRL from a certification revocation list distribution point (CDP) and confirm that the certificate’s serial number is not present. If a CRL has expired, the entity must connect to the CDP to download a new revocation list.

CRLs can be issued by a CA periodically (hourly, daily, or weekly) or as needed. When a certificate is revoked, its serial number is listed in the CRL, and that serial number remains on the CRL at least one period after the certificate’s expiration date. CRLs, like certificates, can be distributed by untrusted servers and untrusted communications.

Under some circumstances, latency (the time between when a certificate is revoked and when the certificate’s serial number appears on the CRL of the issuing CA) may be a concern. For example, if a revocation is reported today, that revocation will not be reliably notified to certificate-using systems until all currently issued CRLs are updated, which may take hours, days, or even weeks. Online revocation checking can reduce the latency between a revocation report and the distribution of the information to relying parties.

If CRL checking is enabled, SBR Carrier uses the URI information contained in a client certificate to connect to the certificate’s CDP. SBR Carrier then uses HTTP, LDAP, or a network file system to retrieve the appropriate CRLs. SBR Carrier stores these retrieved CRLs in the CRLCache directory under the radiusdir server directory.

When a client certificate is presented during EAP-TLS or EAP-TTLS authentication, SBR Carrier can evaluate the client’s certificate chain against its set of stored CRLs to verify none of the certificates in the chain have been revoked.

You can configure the following settings for CRL checking:

Static CDPs—A static CDP is a CDP whose address (URI) is specified in the [Static_CDPs] section of a TLS or TTLS initialization file.
CRL expiration—The CRL checking feature can be configured to operate in strict or lax mode.
- In strict mode, a cached CRL that has expired is immediately discarded; if SBR Carrier cannot acquire a new CRL in the allotted time during a CRL check on a chain, the user is rejected.
- In lax mode, you can configure SBR Carrier to accept an expired CRL for a period past its expiration.
SBR Carrier attempts to obtain a current CRL whether it is running in strict or lax mode.
Missing CDP attribute—When a CRL check is performed on a certificate chain, SBR Carrier reads the contents of the CDP attribute for each certificate past the root certificate and uses the CDP information to retrieve the appropriate CRL. If a non-root certificate in the chain does not contain a CDP attribute, no CRL checking is performed for that certificate. You can configure EAP-TLS to reject the user if it encounters a non-root certificate that is missing a CDP attribute.
Incomplete LDAP CDP—Some CAs may create certificates that contain an LDAP-style CDP (//ldap:\\...) that does not specify the identity of the LDAP server to be queried. You can designate a default LDAP server that is used when such CDPs are encountered. If you do not designate a default LDAP server and an LDAP-style CDP is encountered, the CRL retrieval fails.
HTTP proxies for CRL checking—Network security policy may prevent SBR Carrier from making a direct HTTP connection to a CDP. In such cases, you can configure SBR Carrier to download CRLs through an HTTP proxy server on its local network. Optionally, you can specify the hosts or domains that do not require an HTTP proxy.
CRL cache flushing—You can flush the CRL caches used for EAP-TLS and EAP-TTLS authentication at any time.

Configuring Server Certificates

Valid server certificates must be in place on the SBR Carrier server before you configure the EAP-TLS, EAP-TTLS, and EAP-PEAP authentication protocols. You can add multiple server certificates to the SBR Carrier server.

Note

SBR Carrier does not support DSA type certificates.

Creating a Certificate

To create a server certificate using the Web GUI:

Select RADIUS Configuration > Authentication Policies > Certificates.
The Server Certificates List page (Figure 81) appears.
Figure 81: Server Certificates List Page
Click Create.
The Create Certificate Request dialog box (Figure 82) appears.
Figure 82: Create Certificate Request Dialog
Enter a common name for the certificate in the Common Name field.
Enter a password for the private key in the Password for Private Key field.
Optionally, enter the organization name in the Organization field.
Optionally, enter the organization unit name in the Organization unit field.
Optionally, enter the country or region information in the Country/Region field.
Optionally, enter the state or provision information in the State/Provision field.
Optionally, enter the city or locality information in the City/Locality field.
Optionally, enter the e-mail information in the Email field.
Click OK.
The Create Certificate Request dialog box with links (Figure 83) appears.
Figure 83: Create Certificate Request Dialog with Links
Click the links to download the created certificate and the private key.
Click OK to return to the Server Certificates List page (Figure 81).

Adding a Certificate

To add a certificate to the SBR Carrier server using the Web GUI:

Select RADIUS Configuration > Authentication Policies > Certificates.
The Server Certificates List page (Figure 81) appears.
Click Add.
The Add Server Certificate dialog box (Figure 84) appears.
Figure 84: Add Server Certificate Dialog
Click Browse to browse the location of your server certificate, select the certificate you want to use, and click Open.
Enter the password of the selected certificate in the Password field and click Upload.
The Upload Successful dialog box (Figure 85) appears.
Figure 85: Upload Success Dialog
Click OK. The Server Certificates List page (Figure 86) displays the added certificate details.
Note
By default, SBR Carrier notifies you about the certificate’s expiration five days before the expiration date.
Note
If you upload a certificate file and a key file separately through the Web GUI, SBR Carrier converts these files (of type .cer, .der, or .crt) to the .pfx format and saves it in the server. The name of certificate file will be used for the server certificate name with the extension of .pfx.
Figure 86: Server Certificates List Page with Certificate Details
Optionally, select the Replicate Certificate check box to replicate the added certificate.
Note
This certificate replication setting is applicable only if the SBR Carrier server acts as the primary server.
Configure the Default Certificate from the list of added server certificates. The default certificate will be used as the server certificate for non-realm EAP requests.
Click Apply to save the changes.

Deleting a Certificate

To delete a certificate from the SBR Carrier database:

Select RADIUS Configuration > Authentication Policies > Certificates.
The Server Certificates List page (Figure 81) appears.
Select one or more certification entries that you want to delete.
Click Delete.
Click Apply to save the deletion in the SBR Carrier database.