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.
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.
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.
address 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.
error, check 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 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 subjectAltName.
fully 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.
recommend using 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.
uploaded a 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:
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: '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
Cisco Expressway Certificate Creation and Use Deployment Guide (X8.5.2)
Page 17 of 32
Appendix 1: Troubleshooting