Reference11r1:Concept H.323 over TCP/TLS (H.460.17): Difference between revisions
m (→Configuration) |
m (→Configuration) |
||
| Line 8: | Line 8: | ||
On the PBX incoming H.460.17 registrations are accepted default. There is a new checkmark on devices 'TLS only' which can be used to only allow H.323/TLS registrations. | On the PBX incoming H.460.17 registrations are accepted default. There is a new checkmark on devices 'TLS only' which can be used to only allow H.323/TLS registrations. | ||
In case of TLS, the device certificate can be used for authentication, | In case of TLS, the device certificate can be used for authentication, instead of the password. If a registration with Hardware ID is done, the CN of the device certificate is checked against the registration name. This way the phone can be authenticated towards the PBX without the need to configure any credentials on the phone. | ||
They are two possible matches between the Hardware ID and the Certificate, valid if the CN value on certificate equal to IPXXX-XX-XX-XX (Note some IP2x2 Phones contain an extra letter "s"/"w" for the color in the CN, the Harward ID inserted on the PBX must be equal and also contain the letter to match with the CN) or Serial Number value on certificate equal to 0090XXXXXXXX (Note the 0090 it's not present on the SN of the certificate, however we should include in the Hardware ID field). | They are two possible matches between the Hardware ID and the Certificate, valid if the CN value on certificate equal to IPXXX-XX-XX-XX (Note some IP2x2 Phones contain an extra letter "s"/"w" for the color in the CN, the Harward ID inserted on the PBX must be equal and also contain the letter to match with the CN) or Serial Number value on certificate equal to 0090XXXXXXXX (Note the 0090 it's not present on the SN of the certificate, however we should include in the Hardware ID field). | ||
Revision as of 11:21, 19 June 2015
The standard H.460.17 is an extension to the H.323 standard. It defines a mode of operation to use a single TCP or TLS connection for RAS and call-control within H.323. This is done by tunneling the RAS messages within H.225 signaling messages. This simplifies or even allows different NAT or firewall traversal scenarios. This feature is available starting with version 11. In case of TLS device certificates can be used for authentication of phones at the PBX.
Configuration
Two new protocol selections are available on the phones and in gateway configuration: H.323/TCP and H.323/TLS.
On the PBX incoming H.460.17 registrations are accepted default. There is a new checkmark on devices 'TLS only' which can be used to only allow H.323/TLS registrations.
In case of TLS, the device certificate can be used for authentication, instead of the password. If a registration with Hardware ID is done, the CN of the device certificate is checked against the registration name. This way the phone can be authenticated towards the PBX without the need to configure any credentials on the phone.
They are two possible matches between the Hardware ID and the Certificate, valid if the CN value on certificate equal to IPXXX-XX-XX-XX (Note some IP2x2 Phones contain an extra letter "s"/"w" for the color in the CN, the Harward ID inserted on the PBX must be equal and also contain the letter to match with the CN) or Serial Number value on certificate equal to 0090XXXXXXXX (Note the 0090 it's not present on the SN of the certificate, however we should include in the Hardware ID field).
Homeoffices without VPN
Together with ICE, this feature allows the use of phones in home offices without the need of a VPN connection. Even the PBX may be located inside a private network, provided there is a single mapping on the NAT router to map incoming TCP connections to port 1300 (the well-known port for H.323 over TCP) to the PBX.
Known Issues
- Certificate based authentication only works if the PBX trusts the certificate presented by the phone. Some very old innovaphone phones use a self-signed certificate instead of one that is derived from the innovaphone Device Certification Authority. Such certificates will usually not be accepted. You can check the device certificate by looking at the Device certificate in General/Certificates. If it shows C=DE, O=innovaphone, OU=innovaphone Device Certification Authority as Issuer, it is a valid certificate. If it shows itself as Issuer (that is, if Subject and Issuer are equal), it is a self-signed certificate.
- The PBX must have the "innovaphone Device Certification Authority" - certificate in its own Trust-list, otherwise it will reject the phone certificates signed by it. When a device starts up, it will examine its own device certificate and and put all certificates found in the certificate chain in to its own trust list. As explained above, some very old innovaphone device might miss the proper device certificate. As a result, the certificates in the trust list will be missing too. To solve the problem, you can download the certificate from another device and upload it in the trust-list of the device running the PBX.
- The Gatekeeper Discovery can not be used with TCP/TLS - you must define the Gatekeeper Address in order to get H.323 Registration via TCP/TLS working.
See also
Reference11r1:Concept Using PBX services from public internet