H323 TLS Errors (local only) 3

[EricMcS]

I have an IP Office V2 500 11.x. We are running a mix of end-points: SIP Apps, 54XX, 96XX, J169s. Except for the SIP, the rest are on-site and also remote using IPSec VPN.

All are working except the on-site J169s. We are running them in H.323 mode. The VPN versions are working perfectly, they VPN, download config from the PBX and connect to the call server. The local versions boot, download config from PBX, then fail at login with "Authentication Failure". On the back-end I am getting:

11:12:53 2216231960mS H323Evt: Recv GRQ from 10.1.1.1:49302
11:12:53 2216231961mS H323Evt: e_H225_AliasAddress_dialedDigits alias
11:12:53 2216231961mS H323Evt: found number <4000>
11:12:53 2216231978mS H323Evt: H323PhoneUser Operational: Src=10.1.1.1:48140 Dst=10.1.0.1:1300
11:12:54 2216232012mS PRN: TLS:Alert Src=10.1.0.1:1300 Dst=10.1.1.1:48140 Code=48 Level=Fatal
11:12:54 2216232012mS ERR: TLS:Fatal Error on connection Src=10.1.0.1:1300 Dst=10.1.1.1:48140

Media Security is set to disabled on the PBX and as far as I can tell, the only thing that should be using a certificate is the SIP phones running over TLS. I can't see why the J169 local won't work but the 5610s work and the J169s running over VPN work.

To troubleshoot, I also tried a brand new phone out of the box, reverted to the H323FW and got the same issue; but I brought it home, changed the config to connect to VPN first and it worked.

 

[EricMcS]

SIP ext. Yes, I deleted the H323 ext and created as SIP; and can login using TCP(5060) just not encrypted.

WebRootCA.pem - this doesn't seem to be the case. My phone does not attempt to download "that" file name - but it is trying to download a serialized Root-XXXXXX.pem which contains the correct PEM entries. I am onsite today and still having the exact same issue as from remote... TCP works TLS does not.

 

[EricMcS]

I had all but given up on this. After a week off for vacation, I come back to some random phone issues related to me trying to fix this; but I finally found a setting that resolved my issue.

SET TRUSTCERTS 0

The IPO is creating and offering the correct cert, but it never worked until I changed TLSSRVRVERIFYID from 1 to 0. Just like that it worked. I only have 1 working so far, but will be working on a second one to prove the issue resolved.

 

[kyle555]

If TLSSRVRVERIFYID is 1 then the H323 phone must connect to a FQDN and the cert offered must have a subjectAltName that matches.

## TLSSRVRVERIFYID Specifies whether the identity of a TLS server is checked against its certificate.
## This parameter obsoletes TLSSRVRID for 96x1 H.323 phones.
## 0 Identity of a TLS server is NOT checked against its certificate (default).
## 1 Identity of a TLS server is checked against its certificate. The validation of server identity
## is applicable for IPSec VPN with certificate based authentication (using NVSGIP) , Backup/restore over
## HTTPS (using BRURI), HTTPS file server (using TLSSRVR), WML browser (using WMLHOME),
## H.323 over TLS signaling (using MCIPADD).
## This parameter is supported by:
## J169/J179 H.323 R6.7 and later, J159 and J189 H.323 R6.8.5 and later
## 96x1 H.323 R6.6 and later
## B189 H.323 R6.6 and later

 

[gwebster]

So what you have done is a workaround. You stopped the phone from checking for a valid certificate.

 

[EricMcS]

Worse - I wish it was a work-around. It worked once; I reset the phone and repeated the process and it hasn't worked since. With vacations and remote working, I haven't been in the office much this month, but I still have no working solution for this - just the knowledge that it COULD work, and did once.