[Top] [Prev] [Next] [Bottom]

Managing Certificates

This document describes the Certificate Management software. It has the following sections.

How Certificate Management Works

Entering Certificate Management Commands

Using the Certificate Management Software

Certificate Management Commands

Overview

The Certificate Management module handles all the certificate requirements for IKE and IPSec. A certificate binds a person or entity to a public key using a digital signature. Certificates provide confidence in the public key.

IKE and IPSec use certificates only to authenticate remote peers. IKE does not use the public keys in the certificates for Diffie-Hellman calculations.

Terminology

This document uses the following terminology.

Automatic Enrollment

The process of applying for and receiving certificates online. This implementation does not support automatic enrollment.

Base-64

Base-64 is one of the methods used to encode certificate requests and certificates before they are sent to or from the CA. Some CAs call this encoding PEM. See also DER.

CA

Certificate Authority. A person or organization that creates certificates.

CA Certificate

A CA certificate is used to sign all certificates that the CA issues. A CA certificate contains the CA's public key. If the CA is a root CA, the CA signs the CA certificate with its own private key.

CPS

Certificate Practice Statement. Each CA has a CPS.

CRL

Certificate Revocation List. CRLs contain certificates that have become invalid prior to their expiration date.

DER

Distinguished Encoding Rules as defined in X.509. DER is one of the methods used to encode certificate requests and certificates before they are sent to or from the CA. See also Base-64.

DSA/SHA1

Digital Signature Algorithm/Secure Hash Algorithm-1 (SHA1). This is one of the algorithms the certificate management software uses to sign certificate requests.

End Entity (EE)

The EE is the user of the certificate. In this case, the router is the EE.

Manual Enrollment

Applying for and receiving certificates manually means you need to copy certificate requests from the router and send them to a CA. You also need to retrieve certificates and CRLs from the CA and copy them to the router. This implementation supports only manual enrollment.

PKCS#10

A method the router uses to encode certificate requests that it sends to the CA. Certificate requests are encoded with DER or Base-64.

PKCS#7

A method the CA uses to encode certificates that it sends to the router. By using PKCS#7, a CA can package multiple certificates, such as the Root certificate, Subordinate certificates, and the End Entity certificate in one certificate. The CA encodes certificates with DER or Base-64 format.

Root CA

If your organization is using multiple CAs, the root CA is at the top of the hierarchy. The root CA verifies the signature on all subordinate certificates and on any EE certificates that the root CA issues.

SA

Security Association.

RA

Registration Authority.

RSA

RSA Data Security, Inc. algorithms. Certificate Management supports the RSA/MD5 Message-Digest Algorithm and the RSA/Secure Hash Algorithm-1 (RSA/SHA1).

Subordinate CA

In some applications, there may be multiple CAs in a hierarchy, with a Root CA at the top of the hierarchy and subordinate CAs below the Root CA.

Automatic Enrollment	The process of applying for and receiving certificates online. This implementation does not support automatic enrollment.
Base-64	Base-64 is one of the methods used to encode certificate requests and certificates before they are sent to or from the CA. Some CAs call this encoding PEM. See also DER.
CA	Certificate Authority. A person or organization that creates certificates.
CA Certificate	A CA certificate is used to sign all certificates that the CA issues. A CA certificate contains the CA's public key. If the CA is a root CA, the CA signs the CA certificate with its own private key.
CPS	Certificate Practice Statement. Each CA has a CPS.
CRL	Certificate Revocation List. CRLs contain certificates that have become invalid prior to their expiration date.
DER	Distinguished Encoding Rules as defined in X.509. DER is one of the methods used to encode certificate requests and certificates before they are sent to or from the CA. See also Base-64.
DSA/SHA1	Digital Signature Algorithm/Secure Hash Algorithm-1 (SHA1). This is one of the algorithms the certificate management software uses to sign certificate requests.
End Entity (EE)	The EE is the user of the certificate. In this case, the router is the EE.
Manual Enrollment	Applying for and receiving certificates manually means you need to copy certificate requests from the router and send them to a CA. You also need to retrieve certificates and CRLs from the CA and copy them to the router. This implementation supports only manual enrollment.
PKCS#10	A method the router uses to encode certificate requests that it sends to the CA. Certificate requests are encoded with DER or Base-64.
PKCS#7	A method the CA uses to encode certificates that it sends to the router. By using PKCS#7, a CA can package multiple certificates, such as the Root certificate, Subordinate certificates, and the End Entity certificate in one certificate. The CA encodes certificates with DER or Base-64 format.
Root CA	If your organization is using multiple CAs, the root CA is at the top of the hierarchy. The root CA verifies the signature on all subordinate certificates and on any EE certificates that the root CA issues.
SA	Security Association.
RA	Registration Authority.
RSA	RSA Data Security, Inc. algorithms. Certificate Management supports the RSA/MD5 Message-Digest Algorithm and the RSA/Secure Hash Algorithm-1 (RSA/SHA1).
Subordinate CA	In some applications, there may be multiple CAs in a hierarchy, with a Root CA at the top of the hierarchy and subordinate CAs below the Root CA.

Compatibility and RFCs Supported

The Certificate Management feature supports X.509 v3 certificates for signatures.

Certificate Management implements the following RFCs:

RFC 2314, PKCS #10: Certification Request Syntax Version 1.5
RFC 2315, PKCS #7: Cryptographic Message Syntax Version 1.5

How Certificate Management Works

This implementation supports Manual Enrollment for sending certificate requests to a CA and receiving certificates and CRLs from a CA.

Here is a brief overview of the certificate management process.

: 1. You get a CA's self-signed certificate and copy it to the router.
: 2. Using information that you provide, Certificate Management generates a private/public key pair and a certificate request that are ready to send to a CA.
: 3. You copy the certificate request from the router and send it to a CA.
: 4. The CA then generates and signs a public-key certificate and sends it back to you.
: 5. You copy the certificate to the router and use the certificate management software to retrieve the certificate so that it is ready for use.

About Certificates

End Entity Certificates

The End Entity (EE) is the user of the certificate; in this case, the router is the EE. The EE certificate is the certificate that authenticates the user. The Certificate Management software displays Local as the owner of EE certificates.

CA Certificates

A CA certificate contains the CA's public key. The router uses the CA certificate to verify the router's own certificate when it receives the certificate from the CA. It also uses the CA certificate to verify certificates received from a remote device.

Note: Both the local router and the remote IPSec device must use the same certificate authority.

Types of CA Certificates

There are two types of CA certificates.

Root CA certificates. The root CA provides a self-signed root CA certificate. The root CA certificate validates the CA's own certificates, EE certificates that the CA issues, and CA certificates for each subordinate CA below it in the hierarchy of CAs.

The certificate management software displays RootCA as the owner of root CA certificates.
Subordinate CA certificates. If you are using multiple CAs, you will have subordinate CAs that provide CA certificates. Subordinate CA certificates validate EE certificates that the subordinate CA issues, and CA certificates for each subordinate CA below it in the hierarchy of CAs

The certificate management software displays SubCA as the owner of subordinate CA certificates.

In cases where you are using multiple CAs, the certificate chain, or the hierarchy of CAs, is used to validate the signature on the certificate. The following diagram shows a chain of CAs. When the user New York retrieves a certificate, they receive a certificate, along with CA certificates from Subordinate CA One, Subordinate CA Two, and the Root CA.

Note: You must retrieve the certificate chain into the router in order, starting with the Root CA's certificate.

PKCS#7 Encoding

Some CAs provide the option of encoding the certificates they send to you using PKCS#7. This allows the CA to package multiple certificates into a single envelope. For example, the CA can package an End Entity certificate, the Root CA certificate, and any Subordinate CA certificates into a single certificate. This also allows you to retrieve multiple certificates with one command.

Certificate Requests

A certificate request has three parts:

certificate request information, which consists of the requestor's name, public key, and a set of attributes that identify those using the certificate.
a signature algorithm identifier.
a digital signature on the certificate request information. This implementation uses DSA/SHA1, RSA/MD5, or RSA/SHA1 to sign the request.

To create a certificate, you enter the attributes for a certificate request. The router takes the information that you enter and generates a certificate request, which you then send to a CA. The CA verifies the signature on the request and then creates an X.509 certificate using the information in the request.

Getting the Remote Device's Certificates

The remote device, in most cases, is an IPSec device, such as a security router. The router requests the remote device's certificate during IKE phase 1 negotiations.

The router validates the signature of all remote device certificates using the CA's public key. If a CRL exists, the software checks the CRL for the remote device's certificate. The router rejects invalid remote device certificates and generates an ELS message.

Certificate Revocation Lists

Certificate Revocation Lists (CRLs) contain certificates that were revoked prior to their expiration date. Certificates are revoked due to changes in relationships, such as an employee who ends employment with a company, or due to a private key being compromised.

Certificate Management compares certificates of remote devices and CAs against the CRL as part of certificate verification.

The issuing CA regularly updates the CRL. You need to promptly import the new CRL into the router. (See Putting CRLs Into the Router.) The time between CRL issuances is defined in the CA's Certificate Practice Statement.

The list crl_list command shows the expiration date and time of a CRL, and the date and time when the next update will be available. You can also view information regarding the expiration of a certificate using the list certificate command.

Because you need to manually update CRLs, the Certificate Management module generates ELS messages every hour to remind you when a CRL has expired, and that you should load the next CRL.

When you display the certificate management prompts, the router checks for expired CRLs and displays the following message if one exists.

CRL 'mycrl' has expired.

You will experience a slight delay when you display the certificate prompts while the router checks CRLs.

Interface to IKE

IKE uses certificates in its operations. When IKE negotiates with a peer, IKE requests the peer to send a certificate that a trusted CA has signed. If you have multiple CAs set up in the Certificate Management software, the router requests the peer to send a certificate for each CA configured in the Certificate Management software. The IKE peers negotiate which CA to use.

You can set a preferred CA name in your IKE configuration, which causes IKE to request a certificate only for the preferred CA. You must enter a preferred CA if you have multiple CAs in the Certificate Management software, and you need to use a specific CA for a peer.

To enter a preferred CA, use the preferred_ca=name option with the add peer or set peer commands.

If you enter a preferred CA name, the name must match a CA name you added using the add ca command at the CertMgmt Config> prompt.

Subject Alternative Names

When you submit a certificate request to a CA to be signed, some CAs give you the option of assigning a Subject Alternative Name (SubAltName) to your certificates. If you wish to use a SubAltName, you can set up the IKE software to check EE certificates for the SubAltName, and to verify that the Peer ID matches the SubAltName in the certificate.

The list subject_alternate_name command displays the SubAltName of retrieved certificates. This version of IKE software supports certificates with one subject alternative name.

Setting up IKE to Match the Peer ID to the SubAltName in the Peer's Certificate

1. Display the IPSec configuration prompt.

Config>PROTOCOL ip
Internet protocol user configuration
IP config>ipsec
IPSec Config>

2. Set up the peer to match the peer ID to the SubAltName in the peer's certificate. With this matching set to on, IKE checks the peer ID during IKE negotiations. IKE also checks that the SubAltName in the peer's certificate matches the peer ID.

IPSec Config>set peer win98 match_id = On

3. Set the IKE peer ID to the same value as the SubAltName that you will assign to the peer's certificate.

a. Enter the type of peer ID.

IPSec Config>set peer win98 peer_id_type = email_(User_Fully_Qualified_Domain_Name)

b. Enter the actual peer ID.

IPSec Config>set peer win98 peer_id_value ascii_for_peer_id = abc@nxnetworks.com

Setting Up the Local Peer to Use Its SubAltName as Its Peer ID

You can also set up the local IKE peer to use the SubAltName from the certificate as the ID used when negotiating IKE phase 1 with this peer. To do so:

1. Display the IPSec configuration prompt.

Config>PROTOCOL ip
Internet protocol user configuration
IP config>ipsec
IPSec Config>

2. Set the peer's send_cert_id option to On.

IPSec Config> set peer win98 send_cert_id = on

Entering Certificate Management Commands

You can enter certificate management commands at either the configuration or monitoring prompts. All commands are dynamic, that is, they take affect when you enter them. You do not need to restart the router. You can perform any operation at both prompts, and there is no reason to use one prompt over the other.

Note: You cannot access both the configuration and monitoring prompts at the same time. You also cannot access the certificate prompts when IKE is using the certificate management database for calculating signatures. In these cases, if you attempt to display the prompts, you receive the following message:

Certificate database in use. Please try again.

To display the Certificate Management configuration prompt (CertMgmt Config>), enter certificates at the Config> prompt.

To display the Certificate Management monitoring prompt (CertMgmt>), enter certificates at the Monitor> prompt.

Using the Certificate Management Software

This section shows how to use the Certificate Management software. It has the following sections.

: 1. Before You Begin
: 2. Putting CA Certificates Into the Router
: 3. Requesting Certificates
: 4. Putting Certificates Into the Router
: 5. Putting CRLs Into the Router
: 6. Managing the IBD
: 7. Clearing Your Configuration
: 8. Revoking Certificates

Before You Begin

Before using the Certificate Management software, you need to

add a user that has administrative access to the router software. To do this, enter add user at the Config> prompt.
set the time on the router.

Setting the Time on the Router

You must set the correct time of day and offset from Greenwich Mean Time (GMT) on the router before you set up certificates.

Certificates have a not valid before time, which is the time the certificate was created, and a not valid after time. If the time is not set correctly on the router, and you try to retrieve a certificate into the certificate management module, the router may not accept the certificate.

To check the time set on the router, enter time list at the Config> prompt.

To set the time, enter the following commands at the Config> prompt.

To set the time of day, enter time set.
To set the offset from GMT, enter time offset.

Using FTP or TFTP

You can use FTP or TFTP to move certificate requests, certificates, and CRLs to or from the router.

The router contains an FTP server implementation. To use FTP, you run FTP client software on a PC or workstation to your router's FTP server. You can then use FTP commands such as put or delete.

The router can also act as a TFTP client. The remote host is any device (for example, router, workstation, PC) running IP and acting as a TFTP server. To use the router's TFTP commands, display the Boot config> prompt. You can then use the router's tftp put and tftp get commands.

Config>boot
TFTP Boot/dump configuration
Boot config>tftp get
Enter local filename [CONFIG]?

Enter remote host's IP address or name in host table?

Putting CA Certificates Into the Router

This section shows how to get CA certificates from the CA into the Certificate Management software. You must import the CA certificate into the router before adding the certificates themselves. Failure to do so results in an ELS message and causes the router to reject the certificates.

For certificates that need a chain of certificate authorities, you may need to add several CA certificates. See CA Certificates.

1. In the router software, add a name for the CA.

Note: You must use the same name for the CA as you use for the certificate request and the CRL that you use with the CA.

CertMgmt Config> add ca entr

2. Copy this CA's certificate from the CA. You can do this using your browser software.

3. Use FTP or TFTP to put the CA's certificate into the router IBD.

You can view the contents of the router's IBD file system. In this example, cert4entr in bank 25 is the name of the CA certificate.

Config>boot
Boot config>list ibd
Banks 1-24 contain load "gtx.ldc" which uses 1508186 bytes
     Loaded using TFTP over IP
     Filename gtx.ldc
     Host 0.0.0.0
Bank 25 contains load "cert4entr" which uses 1469 bytes
     Loaded using TFTP over IP
     Filename
     Host 170.170.170.170
Bank 26-60 have been erased

4. In the router software, retrieve the CA's certificate. This makes the CA certificate available to the certificate management software.

Enter the retrieve ca command followed by the CA name and then the CA certificate file name in the router IBD.

CertMgmt Config> retrieve Ca entr cert4entr

Requesting Certificates

This section shows how to create a certificate request and send it to your CA.

1. In the router software, add a certificate request. Include the name of the request with this command. The name of the certificate request and the name of the CA must be the same. In this example, the name is entr.

You must define at least two of the following fields in a request: name, department, or company. Your CA may require that you include other information in a request. Each CA has a Certificate Policy Statement that specifies what must be in a request.

You also specify how the router encodes the request and the key type it uses to sign the request. See add request for all the options you can use with this command.

CertMgmt Config> add Request entr name = Westboro department = Engineering
company = "Nx Networks, Inc." state = MA country = US format = Base-64

At any time in the process you can view the status of a request.

CertMgmt Config> list status entr
Request:                 entr
Subject:                 "Westboro", "Engineering","NxNetworks","MA","US"
Key Type/Len:            RSA/MD5  / 1024
Format:                  Base-64
Status:                  Not submitted

2. In the router software, submit the request. You must include a file name for the request. In this example the file name is entr.req.

CertMgmt Config> submit request entr manual entr.req
Please wait. This may take a while..............
 Certificate Request in IBD/entr.req

Note: When you submit a certificate request with a key type of RSA and a key length of 2048, it can take 20 to 40 minutes before the router completes the calculations necessary to create the certificate request.

The router generates a certificate request and saves it in the router's IBD. You can view the contents of the router's IBD file system.

Config>boot
TFTP Boot/dump configuration
Boot config>list ibd
Banks 1-24 contain load "gtx.rap" which uses 1508186 bytes
Loaded using TFTP over IP
Filename gtx.ldc
Host 0.0.0.0

Bank 25 contains load "entr.req" which uses 1362 bytes
Loaded using TFTP over IP
Filename
Host 0.0.0.0
Banks 26-60 have been erased

3. You can now send the certificate request to the CA. Use FTP or TFTP to copy the certificate request from the router to your PC or workstation. This example uses tftp put at the Boot config> prompt.

Boot config>tftp put ibd/entr.req 192.168.1.3 /gw/gmd/entr.req
TFTP transfer complete, status: OK

4. Send the certificate request to the CA. You can do this using your browser software.

When the CA receives your certificate request, it generates a certificate and sends it to you.

Ensuring Certificates Have Headers and Trailers

All Base-64 (also known as PEM) certificates that you put into the router must have a header and trailer. Most CAs include the header and trailer in certificates they issue. However, some Certificate Authorities do not include the header and trailer. In this case, you need to add the header and trailer before putting the certificate into the router.

X.509 Base-64 certificates need the following header:
```
-----BEGIN X509 CERTIFICATE----- 
```
and the following trailer:
```
-----END X509 CERTIFICATE-----
```
PKCS7 Base-64 certificates need the following header:
```
-----BEGIN XPKCS7 CERTIFICATE----- 
```
and the following trailer:
```
-----END PKCS7 CERTIFICATE-----
```

The following is an example of a PKCS Base-64 certificate:

Putting Certificates Into the Router

This section shows how to get the certificate into the certificate management software.

1. Use FTP or TFTP to move the certificate to the router's IBD. This example uses tftp get at the Boot config> prompt.

Boot config>tftp get ibd/entr.cert 192.168.1.3 /gw/gmd/entr.cert
TFTP transfer complete, status: OK
Boot config>list ibd
Banks 1-24 contain load "gtx.rap" which uses 1508186 bytes
     Loaded using TFTP over IP
     Filename gtx.ldc
     Host 0.0.0.0

Bank 25 contains load "entr.req" which uses 1362 bytes
     Loaded using TFTP over IP
     Filename
     Host 0.0.0.0
Bank 26 contains load "entr.cert" which uses 911 bytes
     Loaded using TFTP over IP
Banks 27-60 have been erased

2. In the router software, retrieve the certificate from the IBD.

In this example, entr is the name of the certificate and entr.cert is the certificate file name in the router's IBD.

CertMgmt Config> retrieve Certificate entr entr.cert

The certificate is now ready for IKE to use. You can view the status.

CertMgmt Config> list status entr
Request:              entr
Subject:            "Westboro", "Engineering", "NXNetworks","MA", "US"
Key Type/Len:         RSA/MD5  / 1024
Format:               DER
Status:               Certificate received for this request
Cert. File:           entr.cert

Putting CRLs Into the Router

This section shows how to get Certificate Revocation Lists from your CA into the router.

1. In the router software, add a name for the CRL.

Note: You must use the same name for the CRL as you used for the certificate request and CA that you use with this CRL.

CertMgmt Config> add crl_name entr

2. Copy the CA's CRL from the CA. You can do this using your browser software.

3. Use FTP or TFTP to put the CRL into the router IBD.

4. In the router software, retrieve the CRL. This makes the CRL available to the certificate management software.

Enter the retrieve crl_list command followed by the name of the CRL and then the CRL file name in the router IBD.

CertMgmt Config> retrieve CRL_list entr Oct12crl

Managing the IBD

Certificate Management uses the router's Integrated Boot Device (IBD) to import and export certificates, certificate requests, and CRLs. It also stores CRLs in the IBD.

The router's IBD stores files in non-volatile flash memory in a series of banks. The number of banks and the size of each bank depends on your router platform. If a file fills more than one bank, you need enough adjacent banks available to hold the file.

Certificate Management requires at least one available bank for each CA plus one additional bank for copying certificates and certificate request. If all IBD banks are in use, the submit and retrieve commands fail.

In most cases, you need to use a bank only for a short period of time. To make sure there is enough space available, you should delete items you no longer need.

Note: Nx Networks recommends that you back up certificate requests and certificates on a local PC before you delete them from the IBD. See Using FTP or TFTP for information on how to move certificate requests and certificates to or from the router.

The following are recommended guidelines for deleting files:

Once you send a certificate request to a CA, delete the request from the IBD.
Once you retrieve a certificate from the IBD, delete the certificate from the IBD.

IBD Commands

You enter commands to manage the IBD at the Boot config> prompt. To display this prompt, enter boot at the Config> prompt.

Config>boot
TFTP Boot/dump configuration
Boot config>

To View the Contents of the IBD

Boot config>list ibd
Banks 1-24 contain load "gtx.rap" which uses 1508186 bytes     Loaded using TFTP over IP
     Filename gtx.rap
     Host 0.0.0.0
Bank 25 contains load "entr" which uses 1469 bytes
     Loaded using TFTP over IP
     Filename
     Host 170.170.170.170
Bank 26-60 have been erased

To Delete a File From the IBD

Boot config>deleteLoadname or Bank Number:entrErasing flash please wait ...

Clearing Your Configuration

Clearing the configuration on a router clears the local certificate, as well as the private/public key pair. Without the private key, the certificate containing the related public key is no longer usable. In such a situation, you should revoke certificates before clearing your configuration.

Revoking Certificates

This implementation does not support the ability to revoke one of its own certificates. To revoke certificates, you must contact the CA by telephone.

Certificate Management Commands

Table 8 describes the Certificate Management commands.

Press Space twice after you type a command to display the available parameters for each command. Enter help for information about using the command line interface.

[C] means the command is available at the CertMgmt Config> prompt.

[M] means the command is available at the CertMgmt> prompt.

Table 8 Certificate Management Commands

Command Description

Add CA [C] [M] Adds a CA name to your configuration.

Add Request [C] [M] Adds and defines certificate requests.

Add CRL_name [C] [M] Adds the name of a Certificate Revocation List request.

Delete [C] [M] Deletes CAs, certificate requests, certificates, CRLs, or keys

List [C] [M] Displays your configuration, as well as the current status of certificate requests.

Retrieve [C] [M] Retrieves certificates and CRLs from the router's IBD.

Set CA [C] [M] Changes the definition of a CA.

Set Request [C] [M] Changes the definition of a certificate request.

Submit Request [C] [M] Submits certificate requests to the IBD.

Table 8 Certificate Management Commands
Command	Description
Add CA [C] [M]	Adds a CA name to your configuration.
Add Request [C] [M]	Adds and defines certificate requests.
Add CRL_name [C] [M]	Adds the name of a Certificate Revocation List request.
Delete [C] [M]	Deletes CAs, certificate requests, certificates, CRLs, or keys
List [C] [M]	Displays your configuration, as well as the current status of certificate requests.
Retrieve [C] [M]	Retrieves certificates and CRLs from the router's IBD.
Set CA [C] [M]	Changes the definition of a CA.
Set Request [C] [M]	Changes the definition of a certificate request.
Submit Request [C] [M]	Submits certificate requests to the IBD.

Add CA [C] [M]

Adds a Certificate Authority alias name to your configuration, and specifies whether the CA provides manual or automatic certificate enrollment. Currently, OpenROUTE software supports only manual enrollment.

Notes:

Both the local router and the remote IPSec device must use the same certificate authority.
You must assign the same alias name to the CA as you assign to the certificate request and CRL that you use with this CA. To differentiate certificates, the software displays the owner of CA certificates as RootCA or SubCA, and the owner of the router's own certificates as Local.

Syntax: add ca alias name mode =

manual

Example: add ca entr mode = manual

Add Request [C] [M]

Adds and defines certificate requests. Each CA has a Certificate Policy Statement that specifies what information you must include in a request.

Notes:

You must assign the same name to the certificate request as you do to the CA certificate and the CRL associated with this certificate. To differentiate certificates, the software displays the owner of CA certificates as RootCA or SubCA, and the owner of the router's own certificates as Local.
The fields name, department, company, state, and country are all optional and you can enter them in any order. However, you must fill in two of either name, department, or company.
While you can submit a certificate request to a CA with just two fields filled in, the CA may not issue a certificate with such limited information.
To use more than a one word name in your request fields, put quotation marks around the name.

The following section describes each of the certificate request parameters. You can change these parameters later using the set request command.

Syntax: add request name

Example: add request default

key_type

Sets the public key algorithm used to sign this certificate request.

Syntax: key_type =

rsa/md5
rsa/sha1
dsa/sha1


Entry	Description
rsa/md5	RSA Data Security, Inc. Message-Digest Algorithm. This is the default algorithm.
rsa/sha1	RSA Data Security, Inc. Secure Hash Algorithm-1.
dsa/sha1	Digital Signature Algorithm/Secure Hash Algorithm-1 (SHA-1).

Example: add request default key_type = dsa/sha1

key_length

The possible key length values depend on the algorithm you selected for the key type. The default key length is 1024.

Syntax: key_length =

768
1024
2048

Example: add request default key_length = 2048

name

Adds the name used in the certificate request.

Syntax: name = name

Example: add request default name = gmd

department

Adds the department name used in the certificate.

Syntax: department = name

Example: add request default department = finance

company

Adds the company name used in the certificate.

Syntax: company = name

To use more than a one word name in your request, put quotation marks around the name. For example,

Example: add request default company = "Nx Networks"

state

Adds the state name to use in the certificate.

Syntax: state = name

Example: add request default state = ma

country

Adds the country name to use in the certificate.

Syntax: country = name

Example: add request default country = US

format

The router can create certificate requests in either DER-encoded format or Base-64 format. The format you use depends on the format your CA supports.

Syntax: format =

DER
Base-64


Entry	Description
DER	Distinguished Encoding Rules (DER) as defined in X.509.
Base-64	Some CAs call this encoding PEM. This is the default setting.

Example: add request default format = Base-64

Add CRL_name [C] [M]

Adds an alias name for a Certificate Revocation List request. After you add the CRL alias name, copy the CRL into the router's IBD and then use the retrieve crl_list command to move the CRL into the Certificate Management software.

Note: You must use the same alias name for the CRL as you used for the CA and for the certificate request that are associated with the CRL.

Syntax: add crl_name alias name

Example: add crl_name entr

Delete [C] [M]

Deletes a CA, specific certificate requests, certificates, and CRLs.

Syntax: delete

ca
request
certificate
crl_list
crl_name
keys

ca

Deletes a CA from your configuration.

Syntax: delete ca name

Example: delete ca entr

request

Deletes a certificate request from your configuration.

This command is useful if you decide not to request a certificate with the configured information. This command is also useful to delete certificate requests for certificates that you have already retrieved.

Syntax: delete request name

Example: delete request default

certificate

Deletes a certificate. The delete command only allows the deletion of certificates in the opposite order in which they were retrieved. This prevents a user from accidentally invalidating a correctly constructed certificate chain.

When you delete a certificate you have the option of also deleting the public/private key pairs associated with the certificate.

Syntax: delete certificate name

Example: delete certificate ssh

1   ssh  RootCA SSH Communic 1024   DSA  Feb 25,2000  Feb 28,2001  0x010E
2   ssh  SubCA  SSH Communic 1020   DSA  Feb 25,2000  Feb 28,2001  0x0115
3   ssh  SubCA  SSH Communic 1022   DSA  Feb 25,2000  Feb 28,2001  0x0116
4   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0117
5   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0118
6   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x011F
7   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0120
8   ssh  SubCA  SSH Communic 1016   DSA  Feb 25,2000  Feb 28,2001  0x0121
9   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0122
10  ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0123
11  ssh Local  SSH Communic 1022   DSA  May  5,2000 Jul  1,2000  0x39130F
Delete certificate #11? (Yes or [No]):  [no]? yes
 This command will delete this certificate.
 You may also delete the private/public keys.
 You will never be able to use this certificate again if the private 
 public keys are deleted.
Delete this certificate? (Yes or [No]):  [no]? yes
Delete the private/public keys? (Yes or [No]):  [no]?

crl_name

Deletes a CRL name that you added using the add crl_name command.

Syntax: delete crl_name name

Example: delete crl_name verca

crl_list

Deletes a Certificate Revocation List (CRL).

Syntax: delete crl_list name

Example: delete crl_list verca

1   verca   VeriSign, In Oct 25,1999  Nov  1,1999  verisigncrl   
Delete CRL #1? (Yes or [No]):  [no]? yes

keys

This command lets you delete obsolete private/public key pairs from the router.

Syntax: delete keys

Example: delete keys boston

This command will delete this private/public key pair.
You will never be able to use the certificate for these keys again.
Do you wish to proceed? (Yes or [No]):[no]? yes

List [C] [M]

Displays your Certificate Management settings, as well as current certificates and CRLs. You can also display the status of your certificate requests.

Syntax: list

ca
all
request
certificate
crl_list
crl_name
status
keys
validity
subject_alternate_name

ca

Shows certificate authorities configured on the router.

Example: list ca

CA Name         Root            Mode
entr            No              Manual

all

Shows your certificate configuration and lists valid certificates, CRLs, and keys.

Example: list all

CA Name         Mode
ssh            Manual

Request        Subject (name, department, company, state, country)
ssh            "Westboro", "Engineering", "Nxnetworks","MA", "US"

Num Cert Owner  Issuer      Length Type Valid From   Valid To Serial Number
1   ssh  RootCA SSH Communic 1024   DSA  Feb 25,2000  Feb 28,2001  0x010E
2   ssh  SubCA  SSH Communic 1020   DSA  Feb 25,2000  Feb 28,2001  0x0115
3   ssh  SubCA  SSH Communic 1022   DSA  Feb 25,2000  Feb 28,2001  0x0116

Key      Length   Type  Public Key Fingerprint 
ssh      1024     DSA   E08EB76BE4381CB72C7066649EB9A968 

CRL             Issuer          Valid From      Valid To  Filename
ssh             No CRL

CRL Name        IBD Filename
jakcrl2         NOT CONFIGURED

request

Gives a brief list of all configured certificate requests. To see if a request was submitted to the CA and if a certificate was received from the CA, use the list status command.

Example: list request

Request        Subject (name, department, company, state, country)
hq             "Westboro", "Engineering", "NxNetworks","MA", "US"

certificate

Lists the certificates added for this local device.

Example: list certificate

Num Cert Owner  Issuer      Length Type Valid From   Valid To Serial Number
1   ssh  RootCA SSH Communic 1024   DSA  Feb 25,2000  Feb 28,2001  0x010E
2   ssh  SubCA  SSH Communic 1020   DSA  Feb 25,2000  Feb 28,2001  0x0115
3   ssh  SubCA  SSH Communic 1022   DSA  Feb 25,2000  Feb 28,2001  0x0116
4   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0117
5   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0118
6   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x011F
7   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0120
8   ssh  SubCA  SSH Communic 1016   DSA  Feb 25,2000  Feb 28,2001  0x0121
9   ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0122
10  ssh  SubCA  SSH Communic 1023   DSA  Feb 25,2000  Feb 28,2001  0x0123
11  ssh  Local  SSH Communic 1022   DSA  May  5,2000  Jul  1,2000  0x3913087


Num	The router assigns a number to each certificate in the order in which the router received the certificate. The numbering restarts for each new Cert name.
Cert	The alias name of the certificate.
Owner	The type of certificate. RootCA—This is the CA certificate from the Root CA. SubCA—A Subordinate CA issued the certificate. Local—The End Entity certificate, the certificate that belongs to this router.
Issuer	The CA that issued the certificate.
Length	The length of the public key contained within this certificate.
Type	The algorithm that the public key within the certificate can be used with.
Valid From	The date the certificate becomes valid.
Valid To	The date the certificate expires.
Serial Number	The number the CA assigned to the certificate, and the number listed in a CRL to revoke this certificate.

crl_list

Lists information about retrieved CRLs.

Example: list crl_list

Name		          Issuer     Valid From          Valid To
hq-CRL        hq-ca      July 7, 2000 1200   July 7, 2001 1300

crl_name

Lists the CRL names that you added using the add crl_name command.

Example: list crl_name

Num CRL    Name IBD Filename 
1          ca1root sshca1root.crl

status

Lists the details and status of certificate requests, including any certificate requests that were sent to the CA and returned in error.

Example: list status hq

Request:              hq
Subject:               "Westboro", "Engineering", "NxNetworks","MA", "US"
Key Type/Len:         RSA/MD5  / 1024    
Format:               Base-64
Status:               Not submitted

keys

Displays the keys in your certificate configuration. The public key fingerprint is an MD5 hash of the public key. It is a 16 byte (128 bit) number regardless of the size of the original public key.

Example: list keys

Key      Length   Type  Public Key Fingerprint 
entrust  1024     RSA   0C7A83492424B3C2D25FCD4547EFFA75 
veris    1024     RSA   2D670B7DB185317C8D767894719A83C0 
verisub  1024     RSA   1D18492086C1569956498DD8FA9A4BF3 
rsa      1024     RSA   5BC17F267C5725F133FD5E78F88FE0D2 
micro    1024     RSA   7338FF430F6833AC1E2547D8F2D6AED9 
xcert    1024     RSA   3188C904F9E2E75F4C74763E908A294E 
ssh      1024     DSA   E08EB76BE4381CB72C7066649EB9A968 
ent2787  1024     RSA   6386871CDEE74CA888A5D1450D9BC669 
ssh2787  1024     RSA   E5DD4166F8C60C0ACAC13A20EF7B7C12

validity

Displays a detailed listing of the valid from and valid to information for certificates and CRLs. In particular, list validity displays the time and date, whereas the list certificates and list crl_list commands display just the date.

Note: These times are Greenwich Mean Time (GMT), or Universal Time, not the time set locally on the router. However, if the Time offset on the router is zero, the local time on the router is the same as GMT.

Example: list validity

Num Cert     Owner  Issuer       Valid From             Valid To               
1   gt57ds1  RootCA SSH Communic Jun 30,2000 13:59:29   Feb 28,2001 11:59:59   
2   gt57ds1  Local  SSH Communic Jan 12,2001 00:00:00+  Feb 15,2001 00:00:00+  
1   gx57rs1  RootCA SSH Communic Jun 30,2000 13:59:29   Feb 28,2001 11:59:59   
2   gx57rs1  Local  SSH Communic Jan 10,2001 00:00:00   Mar  1,2001 00:00:00   
1   gx57rs2  RootCA SSH Communic Jun 30,2000 13:59:29   Jan  1,2060 11:59:59   
2   gx57rs2  Local  SSH Communic Jan 18,2001 00:00:00+  Feb  1,2001 00:00:00+  

 (* = REVOKED; + = EXPIRED) 

 Num CRL      Issuer       Valid From             Valid To              Filename        
1   g57rs12  SSH Communic Jan 19,2001 15:54:01   Jan 19,2001 17:00:00   ca1-crl.pem    
1   gt57ds1  SSH Communic Jan 19,2001 15:54:01   Jan 19,2001 17:00:00   ca4-crl.pem    
1   gx57rm1  SSH Communic Jan 19,2001 15:54:01   Jan 19,2001 17:00:00   ca1-crl.pem    
1   gx57rs1  SSH Communic Jan 19,2001 15:54:01   Jan 19,2001 17:00:00   ca1-crl.pem

subject_alternate_name

Lists the Subject Alternative Name (SubAltName) for all certificates local to the router.

Example: list subject_alternate_name

Num   Cert     Owner    Issuer        Subject-alternate-name 
1     entrust  RootCA   Entrust       No subject-alternate-name present
2     entrust  Local    Entrust       ip=206.175.32.62
1     micro    RootCA   Interop Test  No subject-alternate-name present
1     rsa      RootCA   RSA           No subject-alternate-name present
2     rsa      Local    RSA           aol.com 
                                      xyz@aol.com
1     ssh      RootCA   SSH Communic  No subject-alternate-name present
2     ssh      Local    SSH Communic  http://www.nxnetworks.com 
                                      abc@nxnetworks.com 
                                      nxnetworks.com
1     veris    RootCA   For VeriSign  No subject-alternate-name present
2     veris    Local    For VeriSign  aol.com 
                                      gdeplanche@aol.com
1     verisub  RootCA   For VeriSign  No subject-alternate-name present
2     verisub  SubCA    For VeriSign  No subject-alternate-name present
3     verisub  Local    For VeriSign  aol.com 
                                      xyz@aol.com

Retrieve [C] [M]

Retrieves CA certificates, local certificates, or CRLs from the router's IBD into the certificate management module.

Syntax: retrieve

ca
certificate
crl_list

ca

Retrieves a Certificate Authority's certificate from the IBD, decodes the certificate, and makes it available to the Certificate Management software.

When you receive a CA certificate from the CA, you copy the certificate to the router's IBD and then use this command to retrieve the certificate. For the complete process, see Putting CA Certificates Into the Router.

Upon retrieving the certificate, you can view it with the list certificates command.

When you enter the retrieve ca command, you include the name of the CA you assigned with the add ca command followed by the name of the CA certificate file in the IBD.

Syntax: retrieve ca

CA alias name
IBD file name

Example: retrieve CA entr entcacert2

certificate

Retrieves a certificate from the IBD, decodes the certificate, validates the certificate using the CA certificate, and compares the certificate against the CA's CRL. If the certificate is successfully retrieved, the software makes it available to the Certificate Management software. You can view valid certificates with the list certificates command.

When you receive a certificate from the CA, you copy the certificate to the router's IBD and then use this command to retrieve the certificate. For the complete process, see Requesting Certificates and Putting Certificates Into the Router.

When you enter the retrieve certificate command, you include the name of the certificate you assigned with the add request command followed by the name of the certificate file in the IBD.

Syntax: retrieve certificate

certficate alias name
ibd file name

Example: retrieve certificate default entcertif

Validating certificate. Please wait...

crl_list

Retrieves a Certificate Revocation List (CRL) from the IBD and makes it available to the Certificate Management software.

When you receive a CRL from the CA, you copy the CRL to the router's IBD and then use this command to retrieve the CRL.

When you enter the retrieve crl_list command, you include the name of the CRL you assigned with the add crl_name command followed by the name of the CRL file in the IBD.

Syntax: retrieve crl_list

CRL alias name
ibd filename

Example: retrieve crl_list hqCRL hqCRL23

Set CA [C] [M]

Sets whether certificate enrollment to a CA is automatic or manual. Currently, OpenROUTE software supports only manual enrollment.

Syntax: set ca ca alias name

mode = manual

Example: set ca hq-ca mode = manual

Set Request [C] [M]

Sets or modifies parameters of a certificate request that you previously created.

Once you submit a request, you should not change the request and submit it again. If you do, the router generates a new pair of public/private keys. This means that when the router receives a certificate that was generated from the first request, the keys do not match and the router rejects the certificate.

The same options are available for both the add request and the set request commands. For information on the options, see the add request command.

Syntax: set request alias name

Example: set request default format = Base-64

Submit Request [C] [M]

Using the information you provided with the add request or set request commands, the router creates a certificate request in the format ready to send to your CA. It saves the certificate request in the router's IBD.

CAUTION:
Make sure you do not submit the same request more than once. If you do, the router generates a new pair of public/private keys. This means that when the router receives a certificate that was generated from the request, the keys will not match and the router will reject the certificate.

You need to use FTP or TFTP to get the certificate request from the router. You then need to send the certificate request to the CA. You can do this using your browser software.

When the router creates the request, it generates a public/private key pair. The private key never leaves the router. The public key is included in the certificate request, which is sent to the CA.

Notes:

When you submit a certificate request with a key type of RSA and a key length of 2048, it can take 20 to 40 minutes before the router completes the calculations necessary to create the certificate request.
Once you submit a certificate request, you can delete the request from your configuration. We recommend that you back up certificate requests and certificates on a local PC before you delete them from the IBD. See Using FTP or TFTP for information on how to move certificate requests and certificates to or from the router.
Currently, OpenROUTE software supports only manual certificate requests.

Syntax: submit request

alias name
manual
ibd file name

Example: submit Request default manual hq.req

Please wait. This may take a while..............
 Certificate Request in IBD/hq.req

[Top] [Prev] [Next] [Bottom]