Reference11r1:Certificate management

From innovaphone wiki
Jump to navigation Jump to search
There are also other versions of this article available: Howto | Reference7 | Reference9 | Reference10 | Reference11r1 (this version)

Applies To

This information applies to

  • all innovaphone devices from V9

More information

Certificates are used for TLS connections (HTTPS, SIPS). Normally the client validates the server certificate, takes the public key from it and uses it to exchange a session key for the connection with the server. Therefore the client must trust the certificate of the server.

General configuration hints

Use the General/Certificates page on the administration interface for configuration. Typically you have to

  1. install an appropriate certificate on the server device (e.g. the PBX), if missing.
  2. configure the clients (e.g. the phones, your web browser) to trust it.

Since system time is needed to validate certificates, it is strongly recommended to use an NTP server.

Configuration for HTTPS access to the administration interface

The devices from version 7 come with a built-in certificate signed by innovaphone. Devices upgraded from V6 create a self-signed certificate on first startup. Hence you don't have to do anything to allow for HTTPS access to the administration interface.

Configuration for SIPS

If you are setting up the trust lists for a SIPS environment, make sure that

  • phones trust registrars.
  • registrars trust each other.

Using the Device Certificate for H.323 Device Registration (H.460.17)

The device certificate of an endpoint can be used for registration authentication. See Reference11r1:Concept H.323 over TCP/TLS (H.460.17).

Best practices

If you are planning to deploy custom certificates, it is a good idea to setup your own certification authority (CA). Thus you only have to add a single certificate (the CA certificate) to the trust lists and you don't have to change anything if you add or replace devices. See related articles for additional information.

Naming

In general the common name of the certificate should match the name that is used for accessing the device in the application protocol. For example web browsers try to match the name of the certificate with the host name from the URL.

Additionally there are so called subject alternative names. We support DNS names and IP addresses as alternative names. If a box got a DNS name or a fixed IP address, it is recommended to store that information in the certificate.

Troubleshooting

  • Is the system time set? System time is needed to validate certificates. Configure an NTP server, if required.
  • Does the client trust the server certificate? Check the rejected certificates and add them to the trust list, if required.
  • Are the certificates valid? Perhaps the server certificate has expired or is invalid for its purpose or unsupported. Check the details of the rejected certificates on the client. Install a new server certificate, if required.

Trust list

Certificate trustlist GUI
Certificate details GUI

This list contains the certificates to be accepted for TLS connections. You can add either individual endpoint certificates or a CA certificate if you want to accept all certificates issued by that CA.

Certificate details

  1. Click the subject name to view the details.

Installing a certificate from a file

  1. Select a file.
  2. Press the "Upload" button.
  3. Take a look at the certificate details and check wheather the SHA1 and MD5 fingerprints match with the values published by the owner.

Note: PEM files can contain multiple certificates.

Installing a certificate that was rejected before

See section "Rejected certificates".

Removing single certificates from the trust list

  1. Select the items to remove using the checkboxes.
  2. Press the "Remove" button.

Open TLS connections that are using these certificates will not be closed.

Removing all certificates from the trust list

  1. Press the "Clear" button.

Open TLS connections that are using these certificates will not be closed.

Download

You can download an individual certificate from the trust list in PEM and DER format by clicking the corresponding link. Additionally you can download the complete list as a text file containing the PEM encoded certificates.

Rejected certificates

Rejected certificates GUI

This list contains the certificate chains that were rejected before, while trying to establish a secure TLS connection. This happens for example if the certificate has expired or neither the certificate nor any of the issuing CAs is trusted. If one of that certificates should be trusted for future connections you can select and add it to the trust list, directly.

Certificate details

  1. Click the subject name to view the details.

Removing all certificates from the list

  1. Press the "Clear" button.

Adding rejected certificates to the trust list

  1. Check the certificate details and decide wheather it should be trusted or not.
  2. Select certificates using the checkboxes and press the "Trust" button.

Certificates can only be trusted if they are valid (i.e. not expired).

Fast trust list setup in small installations

  1. Set up your devices without taking care for the trust list
  2. Clear the list of rejected certificates
  3. Make a test run (Shouldn't work!)
  4. Trust the rejected certificates
  5. Make a test run again (Should work this time!)

Revoke List

innovaphone devices do not need or support a list of revoked certificates (Revoke List). The reason is that - as opposed to other solutions - the certificate itself is not sufficient for registration authorisation, it is merely used for authentication. That is, if a device is lost and registration based on that certificate is to be forestalled, it is sufficient to remove the Device entry from the corresponding PBX object.

Device certificate

Creating a self-signed
Creating a certificate signing request
Certificate signing request GUI

The device certificate can be used by remote TLS endpoints to authenticate the identity of the device. In general this is not a single certificate but a chain containing the device certificate and the certificates of the intermediate CAs up to the root CA. A TLS connection can only be established if the remote endpoint trusts at least one of that certificates.

An RSA key pair is associated with this certificate. The certificate that contains the public key is used to authenticate the box to its clients. They can use the public key to encrypt messages for the box and to validate its signatures. The private key is used for decryption and signing and remains on the box.

Certificate Key Length and CPU Usage

Please note that using TLS on the box will consume substantial amount of CPU cycles. Even more, the CPU load imposed by using TLS largely depends on the complexity of the local device certificate used (in the case of mutual TLS (MTLS) also on the complexity of the remote device certificate). Generally, establishing the TLS connection requires 6 times the CPU power when doubling the certificate complexity. The default device certificates shipped with the devices use a SHA256-RSA signature and a 1024 bit RSA public key. If you for example change this to a '4096 bit RSA public key' (key-length quadrupled), the establishment of a TLS connection will take 36 times longer.

We therefore do not recommend to use large key lengths for your device certificates.

Also certificates with SHA1, SHA224 or SHA256 hashes create lower CPU load than SHA384 and SHA512 certificates. For this reason, we recommend SHA256 hashes.

Default certificate

Newly manufactured devices with V7 firmware or higher come with a built-in certificate, signed by innovaphone.

If a device does not have a certificate (e.g. after upgrading from older firmware versions) a new key pair and a self-signed certificate are being created, automatically. It will contain the netbios name of the device (e.g. IP800-06-11-ac) and will be valid for 10 years.

  1. If the certificate has expired, press the "Renew" button to create a new one.

HTTPS and SIPS are deactivated while the default certificate is being created.

Certificate details

  1. Click the subject name to view the details.

Creating a self-signed certificate

A self-signed certificate is not signed with the key of a separate CA but with the key of the owner itself. Therefore the issuer and subject name are the same. Such a certificate cannot be validated by parties that don't know the owner.

  1. Click the "Create new" link.
  2. Select "Self-signed certificate".
  3. Specify the number of years the certificate shall be valid.
  4. Choose the desired key strength or to reuse the old keypair (not recommended).
  5. Specify a distinguished name.
  6. Press the "OK" button.
  7. Wait until the new key pair and the certificate is ready. This may take a long time, depending on the selected key strength.

Creating a certificate signing request

A certificate signing request contains a public key and an identity. While the correponding private key is kept secret, the request is being sent to a CA. It will issue an appropriate certificate for the public key after it verified the identity.

  1. Click the "Create new" link.
  2. Select "Signing request".
  3. Choose the desired key strength or to reuse the old keypair (not recommended).
  4. Specify a distinguished name.
  5. Press the "OK" button.
  6. Wait until the new key pair and the request is ready. This may take a long time, depending on the selected key strength.
  7. Download the request by clicking the PEM and DER link, respectively.
  8. Send the request to your CA.

After you got your certificate from the CA, proceed with section "Uploading a certificate derived from a certificate signing request".

Uploading a certificate derived from a certificate signing request

  1. Select the certificate file.
  2. Click the "Upload" button.

This will only work, if there is a corresponding certificate signing request with the private key on the box.

Deleting a certificate signing request

Warning: The request and its private key will be deleted, permanently. This will deprecate certificates that have been created based on this request!

  1. Press the "Remove" button.

Uploading a certificate chain together with the private key

Warning: It is mandatory to use HTTPS for this operation in order to keep the private key secret!

  1. Select a file.
  2. Press the "Upload" button.

Please use a PEM file containing the certificate chain from the device certificate up to the root CA certificate. Additionally the file must contain the corresponding private key in the PKCS#1 or PKCS#8 format. 

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

Downloading the device certificate

You can download a single certificate from the device certificate chain. For example this is needed if you want to configure your web browser to trust it.

  1. Click the "PEM" or "DER" link of the certificate you want to download.

Deleting the certificate

Warning: This will discard the current device certificate chain and the private key, permanently!

  1. Press the "Clear" button.

The default certificate will be restored. If there is no default certificate, a new one will be created.

Application certificates

Some applications like SIP need a certificate that contains a domain name that differs from the one of the device certificate. For such applications you can create application certificates. They can be created, trusted and deleted in the same way as the device certificate.

Naming

When the application opens a TLS connection it can specify a domain name. In this case TLS tries to find an application certificate that contains the domain name as its common name. If there is no such application certificate, the device certificate is used.

Example: A PBX has system name "example.com". For SIP federation the certificate with common name "example.com" is used.

Root certification authority on Compact Flash card

Setting up a root CA on CF card
Creating a device certificate using the root CA
The newly created device certificate

This is the recommended approach to securely deloying PKI to innovaphone gateways.

  1. The private key of the CA is never being sent over the network or stored on a device.
  2. You only have to add a single certificate to the trust list of your devices.

Setting up the CA

  1. Insert an empty CF card into the card slot of a gateway.
  2. Click the "Root CA" link.
  3. Specify the desired bit strength, validity and distinguished name for the certificate and click the "Create" button.
  4. Wait until the private key and the certificate have been created.
  5. Check the certificate details.
  6. Remove the CF card and keep it at a safe place or continue with creating a device certificate.

Creating a device certificate

  1. Insert the CF card into the card slot of a gateway.
  2. Click the "Root CA" link.
  3. Most probably you want to add the root CA certificate to the trust list of the device. Click the "Trust" button.
  4. Specify the desired bit strength, validity and distinguished name for the certificate.
  5. Select "Backup on CF card", if you want to store the newly created private key and certificate on the CF card.
  6. Click the "Create" button.
  7. Wait until the private key and the certificate have been created.
  8. Check the certificate details.
  9. Remove the CF card and keep it at a safe place.

Reusing the CA with a PC application

Warning: Keep in mind to keep the private key secret!

The following files are stored on the CF card:

  • /CA/cacert.pem: Certificate of the root CA (PEM)
  • /CA/cakey.pem: Private key of the root CA (PEM)
  • /CA/serial.txt: Current serial number (hex string)

Since only standard file types are used, you can easily reuse the CA with your favourite PC application. For example, this is helpful if you started deploying PKI using the CF card and later decide to go for a different approach.

Example: Configuring OpenSSL to use the CA

  1. Insert the CF card into the card reader of your PC.
  2. Add a new CA section to the OpenSSL configuration file.
  3. Use the CA with OpenSSL to sign certificates.
  4. Remove the CF card and keep it at a safe place.

[ my_ca_on_cf ]
cfdir          = ...                       # Path to the CF card drive
certificate    = $cfdir\\CA\\cacert.pem    # The CA certificate
private_key    = $cfdir\\CA\\cakey.pem     # The CA private key
serial         = $cfdir\\CA\\serial.txt    # The current serial number


openssl ca -name my_ca_on_cf ...

Supported features

File formats

  • DER (Distinguished Encoding Rules, Extensions .crt .cer .der)
  • PEM (Personal E-Mail, Extensions .pem .txt)

Certificate types

  • X.509 versions 1-3

Certificate extensions

  • basicConstraints
  • keyUsage
  • extKeyUsage
  • subjectAltName
  • subjectKeyIdentifier
  • authorityKeyIdentifier

Note: Validation will fail, if an unsupported extension is marked as critical.

Signing algorithms

  • md5WithRSAEncryption
  • sha1WithRSAEncryption
  • sha224WithRSAEncryption
  • sha256WithRSAEncryption
  • sha384WithRSAEncryption
  • sha512WithRSAEncryption

Key types

RSA keys

  • 1024-bit (default)
  • 2048-bit
  • 4096-bit

Signing requests types

  • PKCS #10 certification request v1

Related Articles

Retrieved from "https://wiki.innovaphone.com/index.php?title=Reference11r1:Certificate_management&oldid=60643"