Enables privileged EXEC mode.

• Enter your password if prompted.

Enters global configuration mode.

Generates RSA key pairs. Arguments and keywords are as follows:

• general-keys—Specifies that the general-purpose key pair should be generated.

• usage-keys—Specifies that two RSA special-usage key pairs should be generated (that is, one encryption pair and one signature pair) instead of one general-purpose key pair.

• label key-label—(Optional) Name that is used for an RSA key pair when they are being exported. If a key label is not specified, the fully qualified domain name (FQDN) of the router is used.

• exportable—(Optional) Specifies that the RSA key pair can be exported to another Cisco device, such as a router.

• modulus modulus-size—(Optional) IP size of the key modulus in a range 350–2048. If you do not enter the modulus keyword and specify a size, you will be prompted.

• storage device:—(Optional) Specifies the key storage location. The name of the storage device is followed by a colon (:).

• kp1— kp1 is a label name that you select.

Generates EC key pairs.

Declares the trustpoint that your router should use. Argument is as follows:

• name—Creates a name for the trustpoint that you created.

• cube1—Represents the trustpoint name that the user specifies.

Specifies which key pair to associate with the certificate. Arguments are as follows:

• key-label—Name of the key pair, which is generated during enrollment if it does not exist or if the auto-enroll regenerate command is configured.

• key-size—(Optional) Size of the desired RSA key. If not specified, the existing key size is used.

• encryption-key-size—(Optional) Size of the second key, which is used to request separate encryption, signature keys, and certificates.

Generates EC keys for ECDSA cipher suites.

Specifies whether the router serial number should be included in the certificate request. Keyword is as follows:

• none—(Optional) Specifies that a serial number will not be included in the certificate request.

Specifies a dotted IP address or an interface that will be included as "unstructuredAddress" in the certificate request. Arguments and keyword are as follows:

• ip-address—Specifies a dotted IP address that will be included as "unstructuredAddress" in the certificate request.

• interface—Specifies an interface, from which the router can get an IP address, that will be included as "unstructureAddress" in the certificate request.

• none—Specifies that an IP address is not to be included in the certificate request.

Specifies the subject name in the certificate request. Argument is as follows:

• x.500-name—(Optional) Specifies the subject name that is used in the certificate request.

Specifies the enrollment parameters of a certificate authority (CA). Arguments and keywords are as follows:

• mode—(Optional) Registration authority (RA) mode, if your CA system provides an RA. By default, RA mode is disabled.

• retry period minutes—(Optional) Specifies the period in which the router waits before sending the CA another certificate request. The default is 1 minute between retries. (Specify from 1 through 60 minutes.)

• retry count number—(Optional) Specifies the number of times a router resends a certificate request when it does not receive a response from the previous request. The default is 10 retries. (Specify from 1 through 100 retries.)

• url url—URL of the file system where your router should send certificate requests. For enrollment method options, see the enrollment url command.

• pem—(Optional) Adds privacy-enhanced mail (PEM) boundaries to the certificate request.

Allows the certificates of other peers to be accepted without trying to obtain the appropriate CRL or checks the revocation status of a certificate. Arguments are as follows:

• method1 [method2 [method3]]—Method used by the router to check the revocation status of the certificate.

Available methods are as follows:

• crl—Certificate checking is performed by a certificate revocation list (CRL). This is the default behavior.

• none—Certificate checking is not required.

• ocsp—Certificate checking is performed by an online certificate status protocol (OCSP).

(Optional) Specifies the revocation password for the certificate. Argument is as follows:

• string—Name of the password

Exists the current mode.

Obtains the certificates of your router from the certificate authority. The CA server issues two certificates to the trustpoint (CUBE): one to certify the CA server and the other to certify the trustpoint (CUBE). Argument is as follows:

• name—Specifies the name of the CA. Use the same name when you declared the CA using the crypto pki trustpoint command.

Authenticates the CA (by getting the certificate of the CA). Argument is as follows:

• name—Specifies the name of the CA. This is the same name that is used when the CA was declared with the crypto CA identity command.

Imports the certificate given by the CA.

Enters SIP user-agent configuration mode.

Configures the specified TLS version.

Configures the SIP gateway to use its trustpoint when it establishes or accepts TLS connection with a remote device with an IP address.

The trustpoint label refers to the CUBE’s certificate that is generated with the Cisco IOS PKI commands as part of the enrollment proces. strict-cipher means that the SIP TLS process uses only those cipher suites that are mandated by the SIP RFC. When you use the strict-cipher command argument, avoids changes to the configuration if SIP should mandate newer ciphers. The SSL layer in Cisco IOS does not support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Therefore, CUBE actively uses only the TLS_RSA_WITH_AES_128_CBC_SHA suite in strict mode.

Keywords and arguments are as follows:

• remote-addr address—Associates an IP address to a trustpoint.

• remote-addr subnet mask—Associates a subnet mask to a trustpoint.

• default—Configures a default trustpoint.

• trustpoint string—Refers to the SIP gateways certificate generated as part of the enrollment process using Cisco IOS PKI commands

• ecdsa-cipher—Examples are the following: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

  Note	ecdsa-cipher is applicable only for the TLS version 1.2

• curve-size - configures the specific size of elliptic curves to be used for a TLS session.

  384- configures 384-bit Elliptic Curve.

• strict-cipher—Examples are the following: TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

• cn-san-validate server- Enables the server identity validation through Common Name (CN) and Subject Alternate Name (SAN) fields in the server certificate during client-side SIP/TLS connections. Validation of the CN and SAN fields of the server certificate ensures that the server-side domain is a valid entity. While setting up a TLS connection to a target server, CUBE validates the domain name that is configured as destination against the CN/SAN fields in the certificate provided by server. The TLS connection is established only if the domain name that is configured as destination, matches with one of the domain names in the CN/SAN fields of the server certificate that is configured. Once you configure cn-san-validate{server} , validation of the server identity happens for every new TLS connection.

• The keyword tls-profile tag associates all the voice class configurations that are made through the command voice class tls-profile tag . In addition to all the TLS crypto configuration options available under the command crypto signaling , the voice class tls-profile tag command has a keyword sni send .

  sni send enables Server Name Indication (SNI), a TLS extension that allows a TLS client to indicate the name of the server that it is trying connect during the initial TLS handshake process. Only the fully qualified DNS hostname of the server is sent in the client hello. SNI does not support IPv4 and IPv6 addresses in the client hello extension. After receiving a "hello" with the server name from the TLS client, the server uses appropriate certificate in the subsequent TLS handshake process. SNI is supported from TLS 1.2.

  For more information on associating voice class tls-profile tag command to crypto signaling command, see crypto signaling and voice class tls-profile.

  Note

  From Cisco IOS XE Amsterdam 17.3.1a onwards, any new voice class TLS profile configuration option is available only under the command voice class tls-profile tag . You must perform voice class TLS profile configuration under the command voice class tls-profile tag and associate it to crypto signaling command. For example, sni send keyword is available only under the command voice class tls-profile tag . The crypto signaling command continues to support previously existing TLS crypto options. You can use either voice class tls-profile tag or crypto signaling command to configure trustpoint. However, from Cisco IOS XE Amsterdam 17.3.1a onwards, we recommend that you use the command voice class tls-profile tag to perform TLS profile configurations.

Specifies a voice encapsulation type and enters voice service VoIP configuration mode.

Enters this command in SIP configuration mode to enable the TLS port on TCP 5061 to listen.

Configures URLs to either the SIP, SIPS, or TEL format for your VoIP SIP calls. Keywords are as follows:

• sip—Generate URLs in SIP format for VoIP calls. This is the default.

• sips—Generate URLs in SIPS format for VoIP calls.

• tel—Generate URLs in TEL format for VoIP calls.

Ends the current mode.