This information might be a bit dated, but do note that Jabber will behave differently in depending on the version you have. Therefore, what looks like it's working today, could break at the next Jabber update.
I'm sanitizing the below for privacy ---Begin Original Email--- Today I noticed that when I started with a fresh install of Jabber 11.1(2), but did have the Root CA cert installed on my machine, Jabber still warned about the Expressway-E server cert (video.company.com). Have any of you seen that also? I didn't think anything changed with our cert, so I figured it had to be Jabber that changed. So, I uninstalled 11.1(2) and worked my way backwards through the versions until the warning went away. Luckily, I only had to go back to 11.1(0), just two versions back. I compared the logs from 11.1(0) with 11.1(2) and here's the difference. I removed some of the log data for brevity. Notice the blue lines are different, and the entire red section is new in 11.1(2). *GOOD - Jabber 11.1(0)* [csf::http::CurlHttpUtils::curlTraceCallback] - Request #34 post connect phase: 'Connected to video.company.com (A.B.C.D) port 8443 (#0)' [csf::cert::BaseCertVerifier::verifyCertificate] - verifyCertificate using ctx. Identity: Reference identifiers: ['video.company.com']; Identifier to display: 'video.company.com' [csf::cert::BaseCertVerifier::checkIdentity] - About to verify the Subject Alt Name. [csf::cert::CertVerifier::checkIdentifier] - Verifying identity ' video.company.com' [csf::cert::AltNameParserImpl::verify] - Match for 'video.company.com' found in dnsNames index: 0 [csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity succeeded. Matched identifier : 'video.company.com' [csf::cert::PlatformVerificationHandler::handlePlatformVerificationResultSynchronously] - Verification result : SUCCESS reason : [VALID] *BAD - Jabber 11.1(2)* [csf::http::CurlHttpUtils::curlTraceCallback] - Request #3 post connect phase: 'Connected to video.company.com (A.B.C.D) port 8443 (#0)' [csf::cert::BaseCertVerifier::verifyCertificate] - verifyCertificate using ctx. Identity: Mandatory reference identifier: 'video.company.com'; Reference identifiers: ['company.com, 'collab-edge.company.com']; Identifier to display: 'video.company.com' [csf::cert::BaseCertVerifier::checkIdentity] - About to check for an Identity Match. [csf::cert::CertVerifier::checkIdentifier] - Verifying identity ' video.company.com' [csf::cert::AltNameParserImpl::verify] - Match for 'video.company.com' found in dnsNames index: 0 [csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity succeeded. Matched identifier : 'video.company.com' [csf::cert::CertVerifier::checkIdentifier] - Verifying identity 'company.com ' [csf::cert::AltNameParserImpl::verify] - No Match Found for 'company.com' [csf::cert::CertVerifier::checkIdentifier] - Verifying identity ' collab-edge.company.com' [csf::cert::AltNameParserImpl::verify] - No Match Found for ' collab-edge.company.com' [csf.cert.] [csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity: 'company.com' 'collab-edge.company.com' failed. [csf::common::PolicySet::getPolicy] - Successfully found Policy with nature IGNORE_INVALID_CERT_CONDITION [IGNORE_REVOCATION_INFO_UNAVAILABLE_ERRORS] [csf::cert::BaseCertVerifier::applyIgnoreInvalidCertConditionPolicy] - About to enforce ignore invalid cert condition policy. [csf::cert::IgnoreInvalidCertConditionPolicy::removeIgnoredStatuses] - No statuses have been removed from the verification status. [csf::cert::IgnoreInvalidCertConditionPolicy::enforce] - Policy enforced [csf::cert::CertificateDataImpl::parseSubjectCNField] - size of Subject CN field : 17 [csf::cert::CertificateDataImpl::parseSubjectCNField] - Subject CN field : video.company.com [csf::cert::PlatformVerificationHandler::handlePlatformVerificationResultSynchronously] - Verification result : FAILURE reason : [CN_NO_MATCH] So, the problem seems obvious now. Jabber 11.1(2) is checking for *company.com <http://company.com> and collab-edge.company.com <http://collab-edge.company.com>* in the cert, whereas Jabber 11.1(0) was not checking for either. So, I wanted to know more. I went to the MRA guides, and Expressway Admin guide, and I found this passage in the Admin guide: *Select the DNS format and manually specify the required FQDNs. Separate the FQDNs by commas if you need multiple domains. You may select CollabEdgeDNS format instead, which simply adds the prefix collab-edge. to the domain that you enter. This format is recommended if you do not want to include your top level domain as a SAN (see example in following screenshot). * Link: http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway /admin_guide/Cisco-Expressway-Administrator-Guide-X8-5-2.pdf (Page 63 of 403) I found the following section of the Expressway-E configuration for certificates, and I modified/added the two red circled values, then generated a new CSR, followed by signing it again with our private CA. [image: Inline image 1] It fixed the warning in Jabber 11.1(2). ---End Original Email--- On Thu, Jun 9, 2016 at 11:15 AM, Lelio Fulgenzi <le...@uoguelph.ca> wrote: > > Our lab expressway cluster is on it's way to be completed... only thing > missing is the certificates. > > I read up a little on the archives, but still not so clear. > > We're going to be getting individual certs for each Exp-C and Exp-E member > (a cluster of 2xC, 2xE). > > I don't believe I need any SANs for the Exp-C. But I'm not sure if I need > the cluster name in the certificate. > > > - CERT 1: CN=exp-c-a.acme.com, SAN=exp-c-cluster.acme.com > - CERT 2: CN=exp-c-b.acme.com, SAN=exp-c-cluster.acme.com > > > For the Exp-E, I'd like to add the hostname for the outside interface, as > well as the CNAME for the services domain, and the CNAME/ALIAS I'm using > for the collab-edge resolution. > > - CERT 1: CN=exp-e-a.acme.com, SAN=exp-e-cluster.acme.com, > exp-e-a-out.acme.com, myjabber.acme.com, proxy-a.acme.com > - CERT 2: CN=exp-e-b.acme.com, SAN=exp-e-cluster.acme.com, > exp-e-b-out.acme.com, myjabber.acme.com, proxy-b.acme.com > > > In our use case, _collab-edge SRV records resolve to proxy-a and proxy-b, > and those resolve to the exp-e-a-out and exp-e-b-out interfaces > respectively. > > Anything special to get off-prem hardware devices like the 88/98xx , DX > and SX to work properly via MRA? > > --- > Lelio Fulgenzi, B.A. > Senior Analyst, Network Infrastructure > Computing and Communications Services (CCS) > University of Guelph > > 519‐824‐4120 Ext 56354 > le...@uoguelph.ca > www.uoguelph.ca/ccs > Room 037, Animal Science and Nutrition Building > Guelph, Ontario, N1G 2W1 > > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip