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.
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.
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.
fields 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.
certificate, 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
within 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: '
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: '
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
Columbia,C=US,jurisdictionOfIncorporationLocalityName=Dover
Cisco Systems, Inc.
18