Certificates

Last Updated : Mar 06, 2024 |
Prolog information
Metadata
Keywords:
Resource Id: Certificates:80102

Additional Configuration Information

For additional information on certificates, see Certificate Management.
Services between the system and applications can, depending on the settings of the service being used for the connection, require the exchange of security certificates. The system can either generate self-signed certificate or use certificates from a trusted source can be loaded.
Identity Certificate
These settings relate to the X.509v3 certificate that the system users to identify itself when connecting another device using TLS. For example, a PC running IP Office Manager set to Secure Communications.
The system’s certificate is advertised (used) by services which have their Service Security Level set to a value other than Unsecure Only.
By default, each IP Office server provides a self-generated certificate, generated when the system is first installed. However, the certificate can also come from other sources:
  • An alternate identity certificate for the system from added using the Set button.
    • For secondary, expansion and application servers, this can be an identity certificate generated for that server from the web control menus of the primary server.
  • For subscription mode systems, Automatic Certificate Management can be selected. COM then automatically provides the system with an appropriate identity certificate and certificate updates.
Field
Description
Offer Certificate
Default = On.
This is a fixed value for indication purposes only. This sets whether the system will offer a certificate in the TLS exchange.
Offer ID Certificate Chain
Default = On
When enabled, the IP Office advertises a chain of certificates during TLS session establishment.
  • The chain of certificates starts with the system's identity certificate
  • It then adds any certificates it finds in its trusted certificate store with the same Common Name in their "Issued By" Subject Distinguished Name field.
  • If the Root CA certificate is found in the trusted certificate store, that is also included in the certificate chain.
  • A maximum of six certificates are supported in the certificate chain.
Issued To
Default = IP Office identity certificate.
For information only. The common name of certificate issuer.
Certificate Expiry Warning Days
Default = 60, Range = 30 to 180
IP Office Manager can display a warning when a system’s security certificate is due to expire. This setting is used to set the trigger for certificate warnings.
The following settings are only shown for subscription mode systems. They allow COM to provide the system with its identity certificate and to automatically update the certificate when required.
Field
Description
Automatic Certificate Management
Default = Disabled
Supported for subscription mode systems only. When enabled, the system uses an identity certificate supplied by COM along with a copy of the COM root certificate. The maintenance and renewal of the identity certificate and its trust chain are performed automatically.
SAN Details Origin
If the identity certificate issued to the system by COM needs to include any location specific subject alternate name values, this field can be used to define those values.
  • Migrate from existing ID certificate - When generating a new certificate for the system, use the SAN details from its existing identity certificate.
  • Generate form current LAN configuration - When generating a new certificate, create the SAN details from the system's existing LAN and SIP settings.
Automatic Phone Provisioning
Default = Enabled
This additional option is supported when using Automatic Certificate Management. When enabled, phone certificates on phones that support certificate download, are automatically updated when the system identity certificate is updated.
  • New and default phones obtain the certificate using the normal trust on first use process.
  • When an update occurs, the 46xxsettings.txt file is updated to includes details of both certificates. Following a restart, the phones fetch the new certificate using the old certificate details.
The following settings can be used to manage the current identity certificate.
Field
Description
Set
Using Set allows you to load an identity certificate and its associated private key.
  • This control is not shown for subscription mode systems using Automatic Certificate Management.
The IP Office supports:
  • 1024, 2048 and 4096 bit RSA keys. Use of 4096 RSA keys may impact system performance.
  • SHA-1, SHA-256, SHA-384, and SHA-512 signature algorithms. Using signature size larger than SHA-256 may impact system performance.
The source may be:
  • Current User Certificate Store.
  • Local Machine Certificate Store.
  • File in the PKCS#12 format.
    • Pasted from clipboard in PEM format, including header and footer text. This method must be used for PEM (.cer) and password protected PEM (.cer) files. The identity certificate requires both the certificate and private key. The CER format does not contain the private key. For these file types, select Paste from clipboard and then copy the certificate text and private key text into the Certificate Text Capture window.
Using a file as the certificate source
In Manager, when using the file option, the imported file (.p12, .pfx or .cer) can only contain the private key and identity certificate data. It cannot contain additional Intermediate CA certificates or the Root CA certificate. The Intermediate CA certificates or the Root CA certificate must be imported separately into the IP Office Trusted Certificate Store. This does not apply to Web Manager.
Note:
Web Manager does not accept the file of type CER with extension .cer. That file type can only be used in Manager.
View
Displays details of the current identity certificate. The certificate view menu can also be used to install the certificate (but not its private key) into the viewing PCs local certificate store. This can the be used by the PC for secure connection to the system or to export the certificate from the PC.
Regenerate
This command generates a new identity certificate:
  • For system's using the system's own self-generated self-signed identity certificate, this command generates a replacement for the current identity certificate.
  • For subscription mode system's, this command requests a replacement identity certificate from COM. Alternatively, it can be used to request an identity certificate for another server.
Important:
  • Regeneration takes up to a minute, during which time system performance is impacted. Therefore, only perform this action during a maintenance window. The regeneration takes places after saving the security settings.
When clicked, the Regenerate Certificate window prompts you to enter the values in the following table.
Setting
Description
Signature
Default = SHA256/RSA2048.
Select the signature algorithm and the RSA key length to use for the new self-signed identity certificate. The options are SHA256/RSA2048 or SHA1/RSA1024.
Subject Name
Default = None
Specifies the common name for the subject of this certificate. The subject is the end-entity or system that owns the certificate (public key). Example: ipoffice-0123456789AB.avaya.com. If left blank, a system generated subject name is used.
Subject Alternative Name(s)
Default = None
Specify any Subject Alternative Name (SAN) values to include in the certificate.
  • Each entry consists of a prefix, followed by the colon and then the value. Supported prefixes are DNS, URI, IP, SRV and email.
  • Multiple entries can be added, each separated by the comma. The input field has a maximum size limit of 511 characters.
  • Example:  DNS:192.168.0.180,IP:192.168.0.18,URI:SIP:example.com
For Different Machine
Default = Off
This option is only shown for subscription mode systems using Automatic Certificate Management.
When selected, the address details of the other server and the duration of the certificate (maximum 825 days) are requested. After generating the certificate, the browser automatically downloads the certificate file.
Certificate Checks
Field
Description
Certificate Expiry Warning Days
Default = 60. Range = 30 to 180 days.
Set the number of days before the expiry of any stored certificate, at which IP Office Manager, IP Office Web Manager, and System Status Application will display warnings
Use different certificate for SIP telephony
Default = None
The possible settings are None, SIP Trunks or SIP & SM Trunks, SIP Phones.
  • When set to None, all secure telephony communications use the system’s default identity certificate and settings.
  • When set to any other option, an extra set of options similar to those shown for Identity Certificate section are displayed. These can be used to define the certificate used for secure telephony communications. The certificate to use is uploaded to the system’s certificate store using the Set button.
Received certificate checks (Management interfaces)
Default = None.
This setting is used for HTTPS/TLS administration connections to the system by applications such as IP Office Manager when the Service Security Level of the service being used is set to High.
The received certificate is tested as follows:
  • None - The certificate must be in date. No extra checks are made.
  • Low - As above but also:
    • Check the certificate's public key is 1024 bits or greater..
  • Medium - As above, but also:
    • Check there is a trust chain from the Trusted Certificate Store (TCS) to the root Certificate Authority (CA).
    • For IP Office R11.1.3 and higher:
      • Check that the certificate has a key usage defined.
      • If the certificate has extended key usage settings, check they match the purpose for which the certificate is being used.
      • Check that the certificate does not include any unknown extensions marked as critical.
      • Note: For systems upgraded to R11.1.3, these additional checks are only used after the existing setting is changed. For example, changed from Medium to High and then back to Medium. Avaya recommend to backup the configuration before making any changes.
  • High - This settings enables implementation of a strict trust domain where only known certificates are accepted. This is a form of 'certificate pinning' and overcomes the limitation of the standard tree structure PKI where any certificates issued by the root CA are always trusted. High uses the same checks as Medium plus:
    • Check the certificate's public key is 2048 bits or greater
    • Check the certificate is not a self-signed certificate.
    • Not reflected.
    • Check there is a copy of the certificate in the IP Office system's Trusted Certificate Store.
  • Medium + Remote Checks - Use the same checks as Medium plus the following:
    • Perform hostname validation by verifying one of the SAN entries matches the connection's FQDN. If necessary, the SAN entry used can be an IP address.
    • For SIP, verify that the certificate source is authoritative for the SIP domain as per RFC5922.
  • High + Remote Checks - Use the same checks as High plus the same additional checks as Medium + Remote Checks.
Received certificate checks (Telephony endpoints)
Default = None.
This setting sets how the IP Office validates the identity certificate it receives for TLS telephony connections.
  • An identity certificate is not installed in all SIP phones. Therefore, for SIP, the IP Office does not require a client certificate from SIP phones, only from SIP and SM trunks.
The received certificate is tested as follows:
  • None - The certificate must be in date. No extra checks are made.
  • Low - As above but also:
    • Check the certificate's public key is 1024 bits or greater..
  • Medium - As above, but also:
    • Check there is a trust chain from the Trusted Certificate Store (TCS) to the root Certificate Authority (CA).
    • For IP Office R11.1.3 and higher:
      • Check that the certificate has a key usage defined.
      • If the certificate has extended key usage settings, check they match the purpose for which the certificate is being used.
      • Check that the certificate does not include any unknown extensions marked as critical.
      • Note: For systems upgraded to R11.1.3, these additional checks are only used after the existing setting is changed. For example, changed from Medium to High and then back to Medium. Avaya recommend to backup the configuration before making any changes.
  • High - This settings enables implementation of a strict trust domain where only known certificates are accepted. This is a form of 'certificate pinning' and overcomes the limitation of the standard tree structure PKI where any certificates issued by the root CA are always trusted. High uses the same checks as Medium plus:
    • Check the certificate's public key is 2048 bits or greater
    • Check the certificate is not a self-signed certificate.
    • Not reflected.
    • Check there is a copy of the certificate in the IP Office system's Trusted Certificate Store.
  • Medium + Remote Checks - Use the same checks as Medium plus the following:
    • Perform hostname validation by verifying one of the SAN entries matches the connection's FQDN. If necessary, the SAN entry used can be an IP address.
    • For SIP, verify that the certificate source is authoritative for the SIP domain as per RFC5922.
  • High + Remote Checks - Use the same checks as High plus the same additional checks as Medium + Remote Checks.
H.323 Security Level
Default = High (Medium for IP500 systems and systems upgrade to R11.1.3 or higher).
Sets the minimum cipher strength the IP Office accepts on TLS connections for H.323 phones and trunks. Not used for clients where ciphers are enabled and chosen based on those offered by the TLS server.
  • This setting replaces the CIPHER_LEVELS_H232 NUSN used by R11.1.2.x systems.
  • For further details, see the Avaya IP Office™ Platform Security Guidelines manual.
  • Low (0) - Accept low, medium, and high-strength ciphers. Low and medium on IP500 V2 systems.
  • Medium (1) - Accept medium and high-strength ciphers. Medium on IP500 V2 systems.
  • High (2) - Accept high-strength ciphers. Not supported for IP500 V2 systems.
    • For a list of ciphers, see Avaya IP Office™ Platform Security Guidelines.
    • High-strength ciphers are GCM ciphers. These are not supported by any model of IP500 V2 system.
SIP Security Level
Default = High (Medium for IP500 V2 systems and systems upgraded to R11.1.3 or higher).
Sets the minimum cipher strength the IP Office accepts on TLS connections for SIP phones and trunks. Not used for clients where ciphers are enabled and chosen based on those offered by the TLS server.
  • This setting replaces the CIPHER_LEVELS_SIP NUSN used by R11.1.2.x systems.
  • For further details, see the Avaya IP Office™ Platform Security Guidelines manual.
  • Low (0) - Accept low, medium, and high-strength ciphers. Low and medium on IP500 V2 systems.
  • Medium (1) - Accept medium and high-strength ciphers. Medium on IP500 V2 systems.
  • High (2) - Accept high-strength ciphers. Not supported for IP500 V2 systems.
    • For a list of ciphers, see Avaya IP Office™ Platform Security Guidelines.
    • High-strength ciphers are GCM ciphers. These are not supported by any model of IP500 V2 system.
Trusted Certificate Store
This section displays a list of the certificates held in the system’s trusted certificate store and allows management those certificates. Up to 25 X.509v3 certificates can be placed into the store.
When adding a certificate, the source can be:
  • Current User Certificate Store.
  • Local Machine Certificate Store.
  • A file in one of the following formats:
    • PEM (.cer)
    • password protected PEM (.cer)
    • DER (.cer)
    • password protected DER (.cer)
  • Pasted from clipboard in PEM format, including header and footer text.
    This method must be used for PKCS#12 (.pfx) files. Select Paste from clipboard and then copy the certificate text into the Certificate Text Capture window.
SCEP Settings
These settings are used for branch system's which are under centralized management through SMGR.
Simple Certificate Enrollment Protocol (SCEP) is a protocol intended to ease the issuing of certificates in a network where numerous devices are using certificates. Rather than having to individually administer the certificate being used by each device, the devices can be configured to request a certificate using SCEP.
These settings are normally set during the systems initial configuration.
Field
Description
Active
Default = Off.
Request Interval (sec)
Default = 120 seconds. Range = 5 to 3600 seconds.
SCEP Server IP Address/Name
Default = Blank.
SCEP Server Port
Default = 80 for HTTP and 443 for HTTPS.
SCEP URI
Default = /ejbca/publicweb/apply/scep/pkiclient.exe
SCEP Password
Default = Blank.
Related links
System