Cisco Cisco Expressway
Appendix 1: Troubleshooting
SIP TLS negotiation failures on neighbor and traversal zones
If TLS verify mode is enabled, the neighbor system's FQDN or IP address, as specified in the Peer address field of the
zone’s configuration, is used to verify against the certificate holder’s name contained within the X.509 certificate
presented by that system. (The name has to be contained in either the Subject Common Name or the Subject Alternative
Name attributes of the certificate.) The certificate itself must also be valid and signed by a trusted certificate authority.
zone’s configuration, is used to verify against the certificate holder’s name contained within the X.509 certificate
presented by that system. (The name has to be contained in either the Subject Common Name or the Subject Alternative
Name attributes of the certificate.) The certificate itself must also be valid and signed by a trusted certificate authority.
Therefore when certificates have been generated with peer or cluster FQDNs, ensure that the zone's Peer address fields
are configured with FQDNs rather than IP addresses.
are configured with FQDNs rather than IP addresses.
Subject Alternative Name fields longer than 999 characters
If a secure traversal zone or Unified Communications zone fails to come up because of a TLS negotiation error, check
the certificate for a long SAN field.
the certificate for a long SAN field.
The Expressway does not parse SANs beyond 999 characters. So, if there are many alternative names on the certificate,
the Expressway-E's FQDN may be outside of the portion that is read by the Expressway-C.
the Expressway-E's FQDN may be outside of the portion that is read by the Expressway-C.
To avoid or workaround this issue, you need to make sure that any SANs that Expressway needs to trust are fully within
the first 999 characters of the
the first 999 characters of the
subjectAltName
.
Certificates with key length of 8192 bits
SIP TLS zones may fail to become active if certificates with a key length of 8192 bits are used. We recommend using
certificates with a key length of 4096 bits.
certificates with a key length of 4096 bits.
Service failures when using mobile and remote access
Unified Communications mobile and remote access services can fail due to certificate errors if you have uploaded a
private key file that does not contain a trailing newline character.
private key file that does not contain a trailing newline character.
Ensure that the private key file contains a trailing newline character.
Issues with ssh failures and unsupported OIDs
If you experience unknown ssh failures such as ssh tunnels failing to establish, please verify there are no unknown OIDs
in the certificate. This can be done by checking that there are no undecoded numerical entries in the CN of the Issuer &
Subject fields (from the GUI: Maintenance -> Security Certificates -> Server Certificate -> Show(decoded) or from the
console: '
in the certificate. This can be done by checking that there are no undecoded numerical entries in the CN of the Issuer &
Subject fields (from the GUI: Maintenance -> Security Certificates -> Server Certificate -> Show(decoded) or from the
console: '
openssl x509 –text –noout –in /tandberg/persistent/certs/server.pem
’)
Invalid
subject=CN=blahdeblah,OU=IT
Security,O=BigBang,L=Washington,ST=District of
Columbia,C=US,1.3.6.1.4.1.6449.1.2.1.5.1 = #060C2B06010401B2310102010501
Valid
subject=CN=blahdeblah,OU=IT
Security,O=BigBang,L=Washington,ST=District of
Cisco Systems, Inc.
15