01-27-2022 02:43 AM
Hello,
I have an ongoing issue with certificate warnings in my iOS Jabber clients that I can't seem to fix.
Initially I was getting certificate warnings for all Jabber connections (CUCM, IMP, UNITY), but after doing some reading in the documentation and these forums I was able to create valid certificates and deploy them.
The issue now is my Jabber devices are getting a certificate warning when logging in but ONLY for the domain name.
Actions taken so far:
Created certificates (tomcat, xmpp) signed by our internal CA (as per iOS v13 and above requirements)
Added the CA's certificate in the iOS trust store by our MDM solution (verified it is there)
Additional info:
This certificate warnings is not coming up in older iphones (iOS 12.5) so I guess it has something to do with the certificate validation hardening.
If we do not accept the certificate, jabber still connects just fine to all services. This points me to think it may be something needed for third party XMPP clients.
I attached a portion of the jabber logs referring to the certificate validation (changed our actual domain name with "ourdomain")
Can anyone help to resolve this?
Thanks
01-27-2022 05:10 AM
Does your cup-xmpp certificate include the domain in the subject alternate names list? If it's for MRA connections, the domain(s) also needs to be in the subject alternate names list for the E certificate. See below example of our cup-xmpp and E certs.
01-27-2022 05:43 AM - edited 01-27-2022 05:45 AM
Hi Roger,
Thank you for the reply.
Yes, both the certificates (tomcat, xmpp) do have the domain in the SAN list. (I can also see in the logs that the parsed entries of the certificate's SAN list does include the domain).
Looking at logs a little deeper, I can see the reason for the certificate not being trusted is the revocation list.
[csf.cert.utils] [parse] - parsing a leaf cert
[csf.cert.utils] [parseSubjectCNField] - Subject CN field: 'cucmpub-imp-ms.ourdomain.local'
[csf.cert.utils] [parse] - number of Subject Alt Name fields : 3
[csf.cert.utils] [parseDNSField] - parsed dnsName : cucmsub-imp.ourdomain.local
[csf.cert.utils] [parseDNSField] - parsed dnsName : cucmpub-imp.ourdomain.local
[csf.cert.utils] [parseDNSField] - parsed dnsName : ourdomain.local
[csf.cert.utils] [parse] - Basic Key Usage in cert: [DIGITAL_SIGNATURE, NON_REPUDIATION, KEY_ENCIPHERMENT], Extended Key Usage in cert: [SERVER_AUTH]
[csf.cert.utils] [parse] - Cert Public Key type is 'rsaEncryption'
[csf.cert.utils] [parse] - Cert KeyStrength parsed: 2048
[csf.cert.] [doVerifyCertificate] - About to verify the certificate.
[csf.cert.ios] [verifyCertificate] - Checking SSL Policy
[csf.cert.ios] [verifyCertificatePolicy] - Policy verification failed, the urls of CRL Distribution Points and Authority Information Access might be unreachable, result=5
But this is really strange to me since the tomcat certificate (that is signed by the same CA and has the same info for the CRL) is going through the validation without any issues.
[csf.cert.utils] [parse] - parsing a leaf cert
[csf.cert.utils] [parseSubjectCNField] - Subject CN field: 'CUCMPUB-ms.ourdomain.local'
[csf.cert.utils] [parse] - number of Subject Alt Name fields : 5
[csf.cert.utils] [parseDNSField] - parsed dnsName : cucmpub-imp.ourdomain.local
[csf.cert.utils] [parseDNSField] - parsed dnsName : CUCMPUB.ourdomain.local
[csf.cert.utils] [parseDNSField] - parsed dnsName : CUCMSUB.ourdomain.local
[csf.cert.utils] [parseDNSField] - parsed dnsName : cucmsub-imp.ourdomain.local
[csf.cert.utils] [parseDNSField] - parsed dnsName : ourdomain.local
[csf.cert.utils] [parse] - Basic Key Usage in cert: [DIGITAL_SIGNATURE, NON_REPUDIATION, KEY_ENCIPHERMENT], Extended Key Usage in cert: [SERVER_AUTH]
[csf.cert.utils] [parse] - Cert Public Key type is 'rsaEncryption'
[csf.cert.utils] [parse] - Cert KeyStrength parsed: 2048
[csf.cert.] [doVerifyCertificate] - About to verify the certificate.
[csf.cert.ios] [verifyCertificate] - Checking SSL Policy
[csf.cert.ios] [verifyCertificatePolicy] - Policy verification successful
[csf.cert.ios] [verifyCertificate] - Checking Revocation Policy
[csf.cert.ios] [verifyCertificatePolicy] - Policy verification successful
[csf.cert.] [doVerifyCertificate] - Result of platform cert verification: [VALID]
Any ideas are appreciated.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide