Reference16r1:Certificate management
Applies to
This information applies to
- all innovaphone devices from 16r1
General information
The role of certificates in secure communication
Certificates contain a public key (typically an RSA or ECDSA key) and an identity (typically one or more DNS names). They are used in TLS connections (HTTPS, SIPS, H323/TLS, etc.) to validate the identity of the remote endpoint using asymmetric cryptography. This process ensures that endpoints are connected to the intended party and not an impostor.
The pasic principle:
- Handshake and signature
- An endpoint sends its own certificate and creates a digital signature over the handshake data using its private key.
- Validation
- The receiving endpoint validates both the certificate and the signature. It then compares the identity listed in the certificate with the expected identity of the remote party.
- Trust
- To complete this validation, the receiver must know and trust either the certificate itself (self-signed) or, more commonly, the Certificate Authority (CA) that issued it.
In standard TLS connections, the client validates the server's certificate. However, in specific applications (like H.323/TLS), the server may also validate the client's certificate. This is known as Client Authentication or Mutual TLS (mTLS).
Security and performance considerations
The security of a certificate depends heavily on the key type and key size used. As computational power increases annually, key sizes must also grow to mitigate the risk of brute-force attacks. However, longer keys require more CPU cycles for encryption and decryption, leading to a noticeable performance impact.
The primary challenge is finding the "sweet spot": a key size that provides sufficient long-term security without causing unnecessary latency or high server load.
| Security level | RSA key size | RSA performance | ECC curve | ECDSA performance | Status |
|---|---|---|---|---|---|
| 80-bit | 1024-bit | Very fast | - | - | Deprecated |
| 112-bit | 2048-bit | Fast | - | - | Minimum |
| 128-bit | 3072-bit | Moderate | secp256r1 | Fast | Current standard |
| 192-bit | 7680-bit | Ultra slow | secp384r1 | Moderate | Long term |
| 256-bit | 15360-bit | Ultra slow | secp521r1 | Moderate | Ultra high security |
Compatibility considerations
Internal rollout strategy: Support for ECDSA was introduced in version 16r1. Previous versions do not support this algorithm and will fail to establish secure connections if an ECDSA certificate is used.
- Requirement: Update all devices to 16r1 or higher prior to moving to ECDSA certificates.
Interoperability with external systems: On devices that interact with external installations — such as Reverse Proxies and Session Border Controllers (SBCs) — it is advisable to continue using RSA certificates until you are certain that external parties have also upgraded to versions supporting ECDSA.
Certificate rollout
This chapter explains how to deploy certificates and trust lists at scale using automatic tools. This ensures consistency and prevents outages due to expired certificates.
Trust lists
The list of trusted certificates can synchronized on all devices using a "Certificates" configuration in the Devices App.
- See Reference16r1:Concept_App_Service_Devices#Certificates_configuration for details.
- Note: This is automatically configured when setting up new devices using Install. Individual changes can be done in the devices app.
Device certificates
Manual configuration
Certificates and trust lists can also be manually configured on individual devices. This is intended for small-scale testing or troubleshooting. We strongly recommend using automatic deployment for production environments to avoid manual tracking of expiration dates.
Manual configuration in the firmware is performed via the General / Certificates page of the Advanced UI.