Certificate Name Content

Last Updated : Jul 19, 2024 |

The certificate fields Subject and Subject Alternative Name(s) fields have particular significance to IP Office and its various clients.

  • Although the IP Office does not process the Subject Alternative Name(s) field itself, SIP endpoints and other clients require specific content to verify the certificate source. See IP Office VoIP Endpoint Security for more Avaya client information.

  • When requesting or creating identity certificates for IP Office systems, all connected systems that process the received IP Office certificate should be reviewed for their Name and SAN requirements. This should also include any possible future systems connected within the lifetime of the certificate. If in doubt, all possible name entries should be included.

Typical considerations include:

FQDN Options

Description

System FQDN as the Subject Name

The system’s Fully Qualified Domain Name (FQDN) for the Subject Name. If there is no relevant domain name, a meaningful and unique text name for the system should be used as this field can be displayed to users. The Subject Name field should never be empty.

  • Example: ipo.example.com

System FQDN as a SAN DNS Entry

The system’s FQDN as a SAN entry in DNS format. This should always be present if any other SAN entries are required.

This entry is typically used by web browsers and other clients when accessing IP Office using DNS resolution. When used by SIP endpoints, this entry typically should have the value configured in System > LAN1/2 > VoIP > SIP Registrar > SIP Registrar FQDN.

  • Example: DNS:ipo.example.com

Other Domain Names and FQDNs as SAN DNS Entries

Any other domain name or FQDN of the system as one SAN entry in DNS format. This entry is typically used when the system can be accessed using ‘split’ DNS.

  • Example: DNS:ipoffice.example.com

SIP Domains as SAN DNS Entries

Any SIP domains in use as one SAN entry for each SIP domain, in DNS format. This is typically the value configured in System > LAN1/2 > VoIP > SIP Registrar > SIP Registrar FQDN.

This entry is typically used by SIP endpoints, such as the H175, which verifies the server certificate against the SIP Domain it is registering to.

  • Example: DNS:sip.example.com

SIP Domains as SAN DNS SIP Entries

Any SIP domains in use as one SAN entry for each SIP domain, in URI format. This is typically the value configured in IP Office Manager System > LAN1/2 > VoIP > SIP Registrar > SIP Registrar FQDN.

This entry is typically used by SIP endpoints when accessing IP Office using DNS resolution.

  • Example: URI:sip:sip.example.com

LAN1 IP Address as a SAN IP Entry

The IP Address of LAN 1 as one SAN entry in IP format. This entry is typically used by web browsers and other clients when accessing IP Office using the LAN1 IP Address.

  • Example: IP:192.168.42.1

LAN2 IP Address as a SAN IP Entry

The IP Address of LAN 2 as one SAN entry in IP format. This entry is typically used by web browsers and other clients when accessing IP Office using the LAN2 IP Address.

  • Example: IP:192.168.43.1

NAT and Public IP Addresses as SAN IP Entries

Any NAT or public IP Address as one SAN entry in IP format. This entry is typically used by 96x1 H.323 phones in Cloud or Remote Worker deployments, web browsers and other clients when accessing IP Office using the external/public direct IP Address. Note that this entry is not added by default to identity certificates generated by the IP Office Primary Server CA. This entry is needed if phones or other clients are configured to connect to the IP Office’s public IP address and not it’s FQDN.

  • Example: IP:135.11.53.53

SIP IP Address as SAN URI Entries

Any SIP IP Address in use as one SAN entry for each SIP domain, in URI format. This entry is used by the Avaya E129 SIP endpoint when accessing IP Office using an IP Address.

  • Example: URI:sip:135.11.53.53

Wildcard Entries

Under certain circumstances you can use 'wildcard' name to cover all sub-domains within a domain. A wildcard name contains an asterisk, for example *.example.com covers all sub-domains of example.com.

  • The IP Office supports wildcards in both the Subject and Subject Alternative Name(s) name fields. However, this has limitations and increased security risks. See the notes below.

Certificate Name Content Notes

  • Using IP addresses/Private domains

    Most public Certificate Authorities do not support certificates that use IP address and/or private domains. For these public CAs, your certificates should use publicly DNS resolvable domains.

    • Using IP addresses in certificates can compromise the administration of 96xx and other endpoints.

    • 11xx/12xx series phones do not support FQDNs and hence cannot be used with certificates provided by public Certificate Authorities.

  • The certificate Subject Alternative Name can be a domain name or IP address. For Transport Layer Security (TLS) connections, browsers may check that the connection to the site is using a valid, trusted server certificate. If the certificate does not have the correct Subject Alternative Name entry or has an invalid Domain name, the connection can be compromised.

  • Wildcard Certificates

    Wildcard certificates (or certificates with wildcard name fields) carry the following additional risks:

    • Compromise of one server or sub-domain compromises all sub-domains.

    • Replication of the same private key on multiple servers increases the chances of the private key becoming exposed.

    • If the wildcard certificate is revoked, all sub-domains need a new certificate.

    • Wildcard certificates do not work with all server-client configurations.

    • Wildcard certificates are not protected by CA extended validation or warranties.

    • They must not be used to secure more than one IP Office server in a deployment; each server must have a unique identity certificate.

  • IP Office does not support wildcard certificates for use with Avaya SIP clients. That includes Avaya Workplace Client, Avaya Vantage™ or J100 Series endpoints.

IP Office and Server Edition Primary/Linux Application Server support the creation of certificates with up to 8 SAN fields with the following options:

  • DNS – used for hostname or FQDN

  • URL – used for URLs and URIs

  • IP – IP Address.

  • Email – email address

These SAN fields can also be used for Certificate Signing Requests via SCEP.

See Initial Certificate Settings for the default Name SAN fields added on initial certificate creation.

For many straightforward deployments, only a single FQDN as the subject name is required, such as an IP Office Application Server where DNS always resolves itself to the same FQDN.

Other deployments where the identity of the system differs depending upon access (for example, LAN or WAN) or the use of SIP or H323 endpoints with secure signaling, SANs will typically be required.

Related information
IP Office Certificate Support