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 (customers, federated partners, or remote providers) have also upgraded to versions supporting ECDSA.