[cisco-voip] certificates and SANs - what's really needed in there?

Sun Jun 12 09:19:34 EDT 2016

Follow up two....

We ran into the following issues (and resolutions). Hopefully this helps someone who's going through the design phase.

C-E Tunnel Issues: we had errors with the secondary C server trying to establish the tunnel. Turns out you actually _do_ need the cluster name and/or the partner C server in the SAN of the secondary C server certificate. Reissuing the C certs fixed that. 

Cannot Communicate to Server issues: turns out there's a bug that requires the host/domain of the E server to match that which is found in the SRV record results. We had tried to follow our established conventions of naming hosts based on their inside interface and with a data centre subzone. We had to resolve this by modifying the E host name and domain to match the SRV records. N1: it might actually only be domain that matters here, especially if the cert has the correct host name. N2: we ended up scraping the internal and external host names and went with one host name that had different address resolutions based on the split view DNS results. 

Cannot login: we just had to reissue the cert with the domain of the IM&P server added as a SAN. 

In the end, we couldn't get away with single name certs for the C, and ended up getting multi domain ssls for each server. 

Sent from my iPhone

> On Jun 9, 2016, at 5:04 PM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
> 
> 
> Just to follow up, we did add our top domain to the SAN, since we own it. Why not. 
> 
> From reading the notes below, we _don't_ need the "collab-edge.domain.xxx" included.
> 
> We'll see how that goes.
> 
> Worse part is, right now, we don't have any signed certificates for our collab servers, unity or im&p, so we'll still get warnings.
> 
> We'll see how it goes.
> 
> Lelio
> 
> 
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst, Network Infrastructure
> Computing and Communications Services (CCS)
> University of Guelph
> 
> 519‐824‐4120 Ext 56354
> lelio at uoguelph.ca
> www.uoguelph.ca/ccs
> Room 037, Animal Science and Nutrition Building
> Guelph, Ontario, N1G 2W1
> 
> From: "Anthony Holloway" <avholloway+cisco-voip at gmail.com>
> To: "Lelio Fulgenzi" <lelio at uoguelph.ca>
> Cc: "cisco voip" <cisco-voip at puck.nether.net>
> Sent: Thursday, June 9, 2016 3:27:43 PM
> Subject: Re: [cisco-voip] certificates and SANs - what's really needed in there?
> 
> 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 and 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.png>
> 
> It fixed the warning in Jabber 11.1(2).
> 
> ---End Original Email---
> 
>> On Thu, Jun 9, 2016 at 11:15 AM, Lelio Fulgenzi <lelio at 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
>> lelio at uoguelph.ca
>> www.uoguelph.ca/ccs
>> Room 037, Animal Science and Nutrition Building
>> Guelph, Ontario, N1G 2W1
>> 
>> 
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160612/621f1a8a/attachment.html>