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 basic 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 Types

Manufacturer certificate

Every innovaphone device is shipped with a unique, pre-installed certificate signed by the "innovaphone Device Certification Authority 2". This certificate uses the hardware MAC address of the device as the Common Name (CN). For non-hardware endpoints you can obtain a certificate signed by "innovaphone Unverified Device CA", that contains the unverified MAC address.

• Storage: The certificate and its associated private key are stored in a secure hardware area and cannot be modified or removed.
• Typical use cases:
  • Client authentication: Used to identify the device against innovaphone cloud services (e.g., Push Service).
  • VoIP registration: Used for secure client authentication when registering endpoints against the PBX.
  • System fallback: Acts as the default identity if no custom device certificate is present.

Device certificate

For production environments, you can install a custom certificate signed by a publicly trusted CA (e.g., Let's Encrypt) or an internal Corporate PKI. To ensure modern browser and service compatibility, these certificates must include the device's FQDN in the Subject Alternative Name (SAN) field.

• Typical use cases:
  • Server authentication: Provides a trusted identity for HTTPS access.
  • Client authentication: Used for Client Authentication based on DNS names, such as for Federation, Shared Services, or other inter-customer communication.

If no device certificate is installed, the device falls back to the manufacturer certificate. Because the manufacturer certificate contains a MAC address instead of a DNS name, it will trigger security warnings in browsers and may be rejected by external services requiring DNS-based validation.

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 be 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

For certificates for individual devices, we recommend using an ACMEv2 provider (such as Let's Encrypt). The software can automatically obtain certificates from such a provider and renew them before they expire.

• See Reference16r1:Concept_Let's_Encrypt for detailed configuration steps.

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.

Appendix

Supported Parameters

Certificate

• X.509 v3/v2

Key

• RSA
  • 1024-bit (Deprecated)
  • 2048-bit
  • 3072-bit
  • 4096-bit
  • other key sizes can be used but can't be created in the software
• ECDSA
  • secp256r1 (NIST P-256)
  • secp384r1 (NIST P-384)
  • secp521r1 (NIST P-521)

Signature

• ECDSA
• RSA
• RSASSA-PSS with mgf1

Hash

• SHA-256
• SHA-384
• SHA-512
• SHA1 (deprecated, deactivated for new certificates)

File types

• PEM
• DER
• PKCS#12

Change history

For details on supported algorithms in different software versions please seee Howto:Security_works_with_innovaphone.

Hints on constructing PEM files

If you want to create a PEM file containing the private key and the certificate chain for a box, make sure the certificate chain is ordered from the certificate of the endpoint up to the root CA certificate. Each certificate signed by the next one.

Device private key

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQDecOKfxrVdHNZRl8RnpNItpmdSuc+WKAS1UZHbtdH5dUJ7OzG3
ZtW684dkm+mbLP00uY4Qiu25dNg0pKp7svihPU8AvKjoyIS52R2Mtt+/hTpjDfgj
mGFyhMMmziCLaC+oKL4W88sivv7oOjUlBmGHc0JarKoN1q3Yxgcfg4Zk8QIDAQAB
UcVghAbSXJ5G3A3v9POs8UthRMxPrnN2c7DadjZp7Qg=
-----END RSA PRIVATE KEY-----

Device certificate

-----BEGIN CERTIFICATE-----
MIICMTCCAZqgAwIBAgIBATANBgkqhkiG9w0BAQUFADAVMRMwEQYDVQQDDApNeSBS
b290IENBMB4XDTA4MDgxNDA5MDkzM1oXDTExMDgxNDA5MDkzM1owGTEXMBUGA1UE
7HNL76EuQrMmshxYxq0Ay/mlkVc0v7Fp1NzkYn0I2UHpwFZ+zA==
-----END CERTIFICATE-----

Intermediate CA certificate

-----BEGIN CERTIFICATE-----
MIICDDCCAXWgAwIBAgIBADANBgkqhkiG9w0BAQUFADAVMRMwEQYDVQQDDApNeSBS
3FSCPvWfh5nk4e8wIAYDVR0OAQEABBYEFE5lzuLAhex3qtxUgj71n4eZ5OHvMA0G
CSqGSIb3DQEBBQUAA4GBAAepePqAM59TSoZvSPM/XUn3WKbeOa++6842+4Vp9B1c
NmI952d/j/+VsuUXDzPff92IsumPBcch87pksp2GkDrnBvd8WxRsm/n6JF2XS2Ey
-----END CERTIFICATE-----

Root CA certificate

-----BEGIN CERTIFICATE-----
MIICDDCCAXWgAwIBAgIBtpmdSuc+WKAS1UZHbtUFADAVEpG4C3G4CQYDVQQDDApe
cmKMZ+WFAkEA5e4thgPIFPjLtVL2EK7WxMi2msigZ0HeoBfAJHu5K/H01BqUGdwK
hh+ksaW+DStVNG21iuZSQuGwVv56oHj3fQJAdHx+06d7p3G4CA2fdfg24iopluMA
oQN9N7Dfw4RyD+ypsMYz8at9RTEqG8Lc0hujGLgtvBpHUp6wxdUuRw4DJQJAGqn0
PYZSvZvcg7qLLoQYA9oC0xBRCahp2MboUVLHtoDok3BBnH4X+lXRE4jU8VIFH39Z
-----END CERTIFICATE-----

Keys in the PKCS#8 format should look like follows.

-----BEGIN PRIVATE KEY-----
MIICXAIBAAKBgQDecOKfxrVdHNZRl8RnpNItpmdSuc+WKAS1UZHbtdH5dUJ7OzG3
ZtW684dkm+mbLP00uY4Qiu25dNg0pKp7svihPU8AvKjoyIS52R2Mtt+/hTpjDfgj
mGFyhMMmziCLaC+oKL4W88sivv7oOjUlBmGHc0JarKoN1q3Yxgcfg4Zk8QIDAQAB
UcVghAbSXJ5G3A3v9POs8UthRMxPrnN2c7DadjZp7Qg=
-----END PRIVATE KEY-----