Certificate Overview

Last Updated : Oct 08, 2024 |

Public key cryptography is one of the ways to maintain a trustworthy networking environment. A public key certificate (also known as a digital certificate or identity certificate) is an electronic document used to prove ownership of a public key. The certificate includes information about the key, information about its owner's identity, and the digital signature of an entity that has verified the certificate's contents are correct. If the signature is valid, and the person examining the certificate trusts the signer, then they know they can use that key to communicate with its owner.

The system used to provide public-key encryption and digital signature services is called a public key infrastructure (PKI). All users of a PKI should have a registered identity which is stored in a digital format and called an Identity Certificate. Certificate Authorities are the people, processes and tools that create these digital identities and bind user names to public keys.

There are two types of certificate authorities (CAs), root CAs and intermediate CAs. In order for a certificate to be trusted and for a secure connection to be established, that certificate must have been issued by a CA that is included in the trusted certificate store of the device that is connecting. If the certificate was not issued by a trusted CA, the connecting device then checks to see if the certificate of the issuing CA was issued by a trusted CA, and so on until either a trusted CA is found. The trusted certificate store of each device in the PKI must contain the required certificate chains for validation.





IP Office Root Certificate Authority

IP Office generates a self-signed certificate. For IP500 V2 systems, a certificate is generated automatically on the first start up. On Linux systems, a certificate is generated during the ignition process.

The following entities can act as the certificate authority.
  • The Server Edition Primary Server, an Application Server, or a Unified Communication Module (UCM) can act as the root certificate authority for all nodes in the system.

  • In Enterprise Branch deployments, the System Manager can act as the root certificate authority.

  • Identity certificates can also be purchased and issued by a third party certificate authority.

Regardless of the method used to provide the IP Office identity, the certificate authority which signs the IP Office identity certificate must be trusted by all the clients and endpoints that need to establish a secure connection with IP Office. They must be a part of the PKI. Therefore, the root CA certificate must be downloaded to client devices and placed in the trusted certificate store. If there are intermediate CAs in the certificate chain, either the intermediate CAs must be added to the client device Trusted Certificate Store or the certificate chain must be advertised by IP Office in the initial TLS exchange.

Certificates and TLS

Telephony signaling like SIP messaging is secured using Transport Layer Security (TLS). TLS provides communication security using certificates to authenticate the other end of the IP Link.

The message exchange in TLS is aimed at verifying the identity of the communicating parties and establishing the keys that will be used to encrypt the signaling data between the two parties. Typically, the server sends its identity certificate, either self-signed or signed by the CA, to the client. The client must have the CA certificate in its trusted certificate store.

IP Office acts as the TLS server in its interactions with SIP telephony clients. This means that the TLS application on the IP Office must be configured to listen for client connections by enabling TLS in the SIP Registrar on the LAN1 and LAN2 interfaces.

Note:
  • Authentication of the client's certificate by the server is not a requirement. IP Office does not support client certificate validation for all SIP endpoint types.

  • The E.129 phone does not validate the IP Office identity certificate.