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

Thu Jun 9 15:27:43 EDT 2016

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 <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160609/135b9e50/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 63099 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160609/135b9e50/attachment.png>