CMS inbound skype4b read failure code 104

[Gregory Brunn]

I am currently having a problem with skpe 4 business clients calling inbound to cms meetings

Skype for buisness domain is customer.com

Meeting domain is meet.customer.com

The callbridge cert is signed by the same root CA that lync has in its servers trusted store and calls from CMS to skype for business work just fine. 

When attempting the call all I see is the following in the syslog with sip debugging enable.

INFO : SIP trace: connection 427: read failure, code 104

INFO : SIP trace: connection 427: shutting down...

(not giving me much here)

I have seen read code 104 reference in acano docs with tls handshake error.  Can someone confirm for me that the skype for business cert has to be signed by the cert callbridges uses as a trust?  Also what is the best way to check the cert that skype for business send in the tls handshake.

[Zac Colton]

A packet capture of the communication will provide you the details of the certificate exchange.

[Gregory Brunn]

It isn't seen in the capture. I was going to update once I have a resolution but at this point It might be the identify command in the Skype settings not matching correctly with anything in the cert.

[Gregory Brunn]

It isn't seen in the capture. I was going to update once I have a resolution but at this point It might be the identify command in the Skype settings not matching correctly with anything in the cert

[Patrick Sparkman]

Since you mention certificates, make sure both the CMS FQDN and the certificate's CN match.  Skype for Business doesn't like wildcard certificates, as it only looks at the the CN and not the SAN.

[Gregory Brunn]

Are you sure it only looks at the CN have you verified this, TAC told me that their cluster fqdn was not their CN and it worked for them. Can you dive deeper into why the SAN name would not work.

The cms documentation does call out the cluster fqdn however does not have it in the dns appendix so I overlooked this when issues my cert commands.

There are also serial other references that call only the CN but I think the doc writers where just not explaining deep enough, unless I am wrong.

I am still waiting for my Skype for business team to make the change and test.

[Patrick Sparkman]

See the second bullet under the notes section in the Acano KB article: Can I use wildcard certificates.

Lync Front End server only looking at the Common Name of a certificate and matching that name to a Trusted App.

[Gregory Brunn]

Well actually if I read this correctly this is not my problem all outbound connections from cms to Skype don’t fail. It is the other way around lync to cms fail

[Gregory Brunn · Accepted solution]

Well it was 100 percent that the -identity needed to be a fqdn reference in the cert.

This was a doc defect from old docs I was reading.  Also it did not have to be the CN of the cert. It was ok as a SANs.

[ensjsprunger]

I'm sure this has been beaten into the ground, but I find myself struggling with it now and I have a question or two if someone could once again shed some light into it.

Example A: My CMS certificate (CMS 2.4 installation, single combined deployment)

Checking user configured certificates and keys...found
File contains a PEM encoded certificate
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:00:00:00:15:1f:b8:1c:10:e0:5a:ba:dd:00:00:00:00:00:15
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=local, DC=sprnet, CN=SPRNET-CA
        Validity
            Not Before: Oct  5 16:28:28 2018 GMT
            Not After : Oct  5 16:38:28 2020 GMT
        Subject: C=US, ST=Indiana, L=Warsaw, O=Sprunger International, OU=IT, CN=cms01.sprnet.local
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:96:0a:a1:05:e3:cb:8f:f0:ef:8e:8d:c1:0e:ec:
                    6e:be:e5:2a:21:ab:88:f7:c0:1b:83:68:4a:75:82:
                    54:81:bd:6b:f6:38:fa:49:9c:1d:37:ea:90:47:5b:
                    91:1e:a9:fe:33:a0:34:2c:fe:80:f9:e3:b1:14:8f:
                    de:c4:7a:50:6a:02:bc:e9:f9:d0:c4:a7:1c:cb:26:
                    44:e5:43:8c:f5:1e:a8:9c:cd:80:d9:dc:af:75:fb:
                    32:94:a3:5a:a0:88:d8:4c:90:99:c4:59:ac:ca:7f:
                    41:b5:17:26:70:00:7a:08:bf:57:18:c3:eb:bf:a8:
                    57:b3:5a:86:aa:f6:73:ef:45:24:2d:4b:f1:d7:e7:
                    bd:80:af:3a:52:50:55:da:a9:14:89:9d:81:f9:d0:
                    0d:59:b1:b4:72:75:b0:4c:1b:d8:67:0a:2f:4e:02:
                    31:e5:d9:33:b1:a1:c4:46:ed:b6:87:11:48:65:d2:
                    82:56:f2:a2:f8:70:94:99:aa:8f:e4:36:9a:fa:ba:
                    87:9d:4b:eb:3c:56:c2:50:51:1a:fa:29:5a:d8:69:
                    a6:fe:9c:33:60:f9:af:94:c7:40:b1:d6:b4:71:50:
                    c4:0c:03:e9:7f:b3:53:c9:3d:62:a1:2b:7e:01:fe:
                    ce:aa:0e:ee:b8:de:86:b6:e5:6a:40:cf:db:09:c1:
                    2a:49
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:cms01, DNS:sprnet.local, DNS:cms01.sprnet.local, DNS:join.sprnet.local, DNS:cms01.sprnet.local
            X509v3 Subject Key Identifier:
                42:D0:07:3C:DA:B5:16:0C:8A:3B:EC:FF:3A:12:3F:A3:95:30:3D:17
            X509v3 Authority Key Identifier:
                keyid:AB:9A:C3:DB:F3:1F:0B:F8:8F:6E:A6:75:AB:B1:86:1E:6B:F9:8E:46

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:ldap:///CN=SPRNET-CA,CN=wincert02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=sprnet,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint

            Authority Information Access:
                CA Issuers - URI:ldap:///CN=SPRNET-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=sprnet,DC=local?cACertificate?base?objectClass=certificationAuthority

            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            1.3.6.1.4.1.311.21.7:
                0+.#+.....7.....j.........<..,....B...H..d...
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            1.3.6.1.4.1.311.21.10:
                0.0
..+.......0
..+.......
    Signature Algorithm: sha1WithRSAEncryption
         82:2a:6d:00:1c:b1:65:33:d3:95:d7:34:de:53:f9:36:7c:7a:
         5a:fb:2c:d4:dd:f9:11:96:78:e3:a6:36:ba:d5:09:27:df:6b:
         54:54:55:ca:23:b9:53:4f:da:0a:ff:af:9f:f3:bb:7e:60:87:
         21:01:e3:d4:7b:f8:f2:71:18:79:10:be:c6:91:59:0e:da:db:
         5b:c2:ad:ca:6d:fb:20:a9:c9:ab:28:7b:81:1f:f4:c4:e0:6e:
         74:ea:97:a7:d2:7b:30:56:bb:d9:9f:14:c4:cf:90:a2:6c:23:
         83:60:23:76:67:31:a8:fb:72:c4:f4:bd:85:e3:d5:1f:b1:96:
         a7:02:e0:aa:ca:3d:f6:f3:8d:5d:38:74:e1:11:29:86:f6:17:
         4b:55:c1:f7:18:16:77:13:bd:e0:2f:ed:0e:01:df:93:26:d8:
         75:b1:3e:b9:f0:5e:aa:c0:33:a7:ec:99:d4:11:6b:eb:87:8b:
         5b:2f:11:4e:b3:12:42:4e:a2:47:1b:62:4d:80:f5:40:96:4e:
         b1:b2:b8:12:23:95:a8:a5:23:18:60:be:a8:01:fa:b9:6a:f6:
         d3:bd:a3:b0:16:27:30:c8:ca:41:a1:97:1b:01:d1:bc:26:96:
         19:18:7f:6d:88:f0:c8:6f:07:7b:b2:bc:4a:ef:71:60:38:7d:
         ee:39:42:30:77:e8:d7:da:18:b3:69:f1:11:a7:7b:2b:a8:3a:
         43:28:4d:de:ca:6e:1b:82:92:71:f7:71:28:70:7d:20:ad:9b:
         dd:0d:c8:b9:95:ca:8d:47:73:d1:f1:17:72:65:a0:34:99:87:
         19:0d:ba:c9:17:95:80:5b:85:25:9e:f5:82:42:87:5a:bc:38:
         da:18:99:e8:16:fd:8d:ab:fb:aa:ab:3f:ce:75:da:29:41:f0:
         19:2d:82:31:8e:42:62:e3:10:99:af:14:2c:11:d4:a6:05:42:
         ae:94:7a:af:16:64:d3:d3:ce:f2:3d:91:e5:6c:5a:ad:0c:79:
         49:a6:ef:6b:bd:87:28:50:57:89:69:71:2e:9a:ee:d6:16:df:
         98:d7:14:f3:03:40:6a:a9:ca:bf:40:dc:c3:6d:89:c7:64:88:
         f2:01:f3:27:d9:d8:2c:6d:c8:73:e0:6f:a0:c8:d8:5f:05:f2:
         0e:77:e1:ba:47:6c:2e:2b:7f:e0:1d:ed:2a:5b:ca:93:97:b6:
         d7:8c:f5:ee:10:50:e4:be:38:66:35:d3:5d:58:4a:42:de:aa:
         b0:39:0a:d5:f9:7c:e3:dd:6d:df:39:84:89:8a:7b:7d:0b:ba:
         0d:3b:b3:c7:25:8b:4a:ef:79:e6:44:36:80:94:01:86:55:34:
         78:62:06:a5:d3:14:43:6b

Example B: My S4B 2015 Trusted Application Pool

Identity             : TrustedApplicationPool:cms01.sprnet.local
Registrar            : Registrar:winskype01.sprnet.local
FileStore            :
ThrottleAsServer     : True
TreatAsAuthenticated : True
OutboundOnly         : False
RequiresReplication  : False
AudioPortStart       :
AudioPortCount       : 0
AppSharingPortStart  :
AppSharingPortCount  : 0
VideoPortStart       :
VideoPortCount       : 0
Applications         : {}
DependentServiceList : {}
ServiceId            : 1-ExternalServer-1
SiteId               : Site:LAB
PoolFqdn             : cms01.sprnet.local
Version              : 7
Role                 : TrustedApplicationPool

--

As I've read the documentation and the threads on this topic, if my CN: and My Identity match (as they appear to above) I should be able to get past the infamous 104 error, correct? I am having no such luck.

SIP trace: connection 765: allocated for outgoing encrypted connection to 10.10.30.100:5061
2018-10-05	13:58:19.531	Info	SIP trace: connection 764: shutting down...
2018-10-05	13:58:19.550	Info	SIP trace: connection 765: outgoing secure connection successful, 10.10.100.30:49566 to 10.10.30.100:5061
2018-10-05	13:58:19.550	Info	SIP trace: connection 765: outgoing SIP TLS data to 10.10.30.100:5061 from -:0, size 514:
2018-10-05	13:58:19.550	Info	SIP trace: REGISTER sip:sprnet.local SIP/2.0
2018-10-05	13:58:19.550	Info	SIP trace: Via: SIP/2.0/TLS 10.10.100.30:5061;branch=z9hG4bKaa5fae07fd4ab722024982243e0aabdd
2018-10-05	13:58:19.550	Info	SIP trace: Call-ID: 04848d89-b2b6-494d-8bfd-e24c5a9065df
2018-10-05	13:58:19.550	Info	SIP trace: CSeq: 41559913 REGISTER
2018-10-05	13:58:19.550	Info	SIP trace: To: <sip:cms01serviceuser8@sprnet.local>
2018-10-05	13:58:19.550	Info	SIP trace: From: <sip:cms01serviceuser8@sprnet.local>;tag=9d06ac6b8b7127c8;epid=acano
2018-10-05	13:58:19.550	Info	SIP trace: Max-Forwards: 70
2018-10-05	13:58:19.551	Info	SIP trace: Event: registration
2018-10-05	13:58:19.551	Info	SIP trace: Supported: ms-userservices-state-notification
2018-10-05	13:58:19.551	Info	SIP trace: Contact: <sip:cms01serviceuser8@sprnet.local;transport=tls>;isFocus
2018-10-05	13:58:19.551	Info	SIP trace: User-Agent: Acano CallBridge
2018-10-05	13:58:19.551	Info	SIP trace: Content-Length: 0
2018-10-05	13:58:19.553	Info	SIP trace: connection 765: read failure, code 104
2018-10-05	13:58:19.553	Info	SIP trace: connection 765: shutting down...

I am sure am I doing something silly but I would appreciate another set of eyes.

So many thanks in advance!

Justin

[ensjsprunger]

Nevermind, when in doubt, check your CMS routing.

Issue resolved. Thanks again.

Justin

[Gregory Brunn]

Your Skype for business is signed by the same CA that you used to sign that cert, correct?