TLSandCertGuidelineforR7 1 Ver 0 1

TLS & Certificate Management Guidelines for CM R7.
1
(includes Gateways & H.323 IP Phones)
March 2, 2017
Development/Tier 4 Engineers: Wayne Zakowski,

Shlomi Biton, Ron Blechman and Jim Corliss
Scope of this Document
 This document has been created for the R7.1 Commercial/Government
customers to guide them through the administration and certificate
management of the Communication Manager, G430/G450 gateways, and the
96x1-H.323 phones for the purpose of deploying TLS links in their enterprise
networks.
 When Release versions are listed, this is to always be interpreted as “Release
X or greater).
Avaya – Proprietary. Use pursuant to Avaya policy. 2

Table of Contents
 CM Port Utilization & Product Release Requirements
 What Is the TLS Protocol & How Are Certificates Used
 Certificate Management – Summary of Product Support (CM, G4xx Gateways,
96x1 H.323 Phones)
 Administration of Avaya Aura® Communication Manager
 Administration of Avaya H.323 96x1 Phones
 Administration of Avaya G430/G450 Gateways
 Appendix A: Certificate Management for CM Duplex Servers
 Appendix B: Creating SMGR Signed Certificates for CM
 Appendix C: Certificate Signing Request for SMGR Signed Certs
 Appendix D: Certificate Signing Request for Commercial CA Signed Certs

CM Port Utilization & Product Release
Requirements
 The Customer’s Security Administrator must enable the following ports to support
TLS links to gateways and H.323 phones:
 TCP port 1300 is used for the TLS signaling connection to the H.323 phones.
 TCP port 2944 is used for the TLS connection to tunnel the H.248 control channel
between CM and the G430/G450 gateways.
 Product Release Requirements
 CM Release 7.1
 CM does not require being placed into FIPS mode.
 CM supports the option of “TLS Min Version” on ‘Server Access’ SMI page.
 96x1-H.323 Phone Release 6.6.2- Load 27 (or newer)
 Only 96x1-H.323 phones will support the feature of TTS-TLS
 G430/G450 Release 7.1 – load 38.15.0 (or newer)
 Administration setting for “TLS Min Version”.
 Administration setting enhancement for CRL/OCSP and for SubjectAlternate field
checking for certificates.

How TLS & Certificates Are Used
 TLS encryption is used for secure connections across control links
– CM 7.0.1 offers the ability to create TLS connections for:
• CM to H.323 phone signaling channel
• CM to H.248 control channel
– CM may operate in FIPS mode or not in FIPS mode to support TLS.
 TLS is a client-to-server protocol
– Exchanges crypto list and version
– Exchanges identity certificates for validation
• Name fields
• Signing authority
• Digital signature for this certificate
 Avaya’s approach for cert management is to:

– Offer new Product Identity certificates and Trusted CA certificates with enhanced
signatures (SHA2 and 2048 key length)
– Be able to receive and validate both:
• Existing certificates with signature (SHA1-1024)
• New certificates with signature (SHA2-2048).

Example of SSL/TLS Protocol Handshake
Handshake Protocol
Server Client
ClientHello
Session ID
Random Data
Session ID ServerHello
List of Cipher Suites
Random Data
List of Compress Algorithms
Cipher Suite selected
Version List Supported
Compress Algorithms selected
Lower common version selected Server Identity Certificate
CertificateRequest
ServerHelloDone
Client Identity Certificate
ClientKeyExchange
CertificateVerify
ChangeCipherSpec
EncryptedHandshakeMessage
ChangeCipherSuite
EncryptedHandshakeMessage
Record Protocol Exchange

Summary of Cross-Certification Process
for Avaya Aura Solution Components
Root CA
Trust
Anchor
Intermediate
CA
PKI
End-Entity End-Entity End-Entity
CM Identity GW Identity H.323 Phone Identity

Summary of Certificate Management
across Solution Components

CM’s Certificate Application Directories
 CM has four application directories to hold possible certificates:

– C => CM Communication Links
• SIP Trunks, H.248 Gateways, H.323 Phones
– W => Apache Web Services (HTTPS)

– R =>Remote Logging
– A => AAA
• LDAP, Radius, etc.
 Security Administrator may download certificates from hosted server

(where certificates are built).
 If application certificate sets (Identity cert, Trusted chain) is not
loaded, there will be no TLS established.
 For the purpose of establishing TLS links to phones and gateways, we
are only concerned with the “C Identity certificate” on CM.

TLS Links Employed on Communications Manager
Communication Manager
Web-Based
Application
HTTPS Apache Remote Serviceability Remote
Server Web Logging
TCP 443 Logging
Services Service Server
W
R
Peers SIP Signaling

(CM,SM) TCP 5061 AAA
Serviceability
Communication AAA
User Server
Service
H.248 Signaling
G4xx Services
TCP2944
Gateway A
H.323
H.323 Signaling
–96x1
TCPxxxxx out Trusted Repository
NOTE:
TCP 1300 inward
CA CA CA 1)Load CA cert chain for
AES AES (TCP 8765) 1 2 3 who signs the CM ID
cert, plus who signed all
of the peer TLS entitites.
CM Dup (TCP 12080) 2) 2) Load CM Identity
Cert.
CM
Filesync (TCP21874)
Peer

96x1 H.323 Phone Certificate Application
 96x1 H.323 phone has a single application directory to store the certificate set
(Identity cert and Root-CA).
– CM H.323 Signaling channel to phone.
 If an application certificate set (Identity cert, Trusted chain) is not loaded, there
will be no TLS established for this application under Mutual authentication.
– In order to build an environment in phases, if CM is set for “Mutual Authentication”
set to “no”; and the administrator does not load an Identity Certificate on the phone,
then CM will allow the endpoint to open a TLS session without authenticating a
phone certificate.
– If the phone contains an Identity certificate for 802.1X or VPN applications (and not
for the H.323 signaling/registration over TLS), then CM shall include the Root CA
certificate in the CM’s Trust repository. In this case, independent of the Mutual
Authentication flag, CM will be able to verify these other certificates, which the
phone has exchanged.
 96x1 Phones support Identity certificates which have a digital signature of
(SHA2 and RSA 2048 key lengths).

TLS Links Employed on 96x1 H.323 Phone
H.323 Signaling
TCP 1300
96x1 H.323 Phone
CM
SSO –
TCP/18414
PC CA
OCSP –
Directory
OCSP over HTTPS TCP/443
Certificate
CA 1 CA 2
SLA Monitor Serviceability Directory
CA for CA for
Server {Discover on SSO 802.1x
UDP 50011} EAP-TLS
{TLS on TCP NOTE:
50010} 1) Load CA cert chain
CA 3 CA 4 for who signs the CM
Radius 802.1x EAP-TLS Identity cert.
Server CA for CA for 2) Load Phone Identity
CM SLA Mon Cert.
Configuration
files download CA 5 3) Administrator may
TCP/411 decide to have the SAME
HTTP/S file Configuration CA for a few
server Backup/restore & applications.
files download
debug report
4) Up to 6 trusted
TCP/443 Cert certificates files are
CA 6
supported.
WML browser
Phone Identity
WML server TCP/443 IPSec VPN
IKE TCP/UDP
500/2070/4500
IPSec VPN Gateway to 500/4500

G4xx Gateway Certificate Application Directories
 Gateway has two application directories to hold possible certificates:

– CM H.248 Control Channel
– SLA Monitor
 The commands used to download, remove, show are offered via the gateway
CLI interface.
 If an application certificate set (Identity cert, Trusted chain) is not loaded, there
will be no TLS established for this application.
 Gateways support Identity certificates which have a digital signature of (SHA2
and RSA 2048 key lengths).

TLS Links Employed on G4xx Gateways
G4xx Gateway
CM
H248reg App H248reg App NOTE:
H.248 Signaling
Certificate CA 1)Load CA cert chain for
TCP 2944 who signs the CM cert.
Directory Directory
2)Load GW Identity Cert.
Cert
1 CA
1
GW Identity
SLA Monitor
SLA SLA
Serviceability Server
Certificate CA
{Discover on
Directory Directory UDP 50011}
{TLS on TCP
Cert
2 CA 50010}
2
GW Identity

Notes about Building Certs
 For Avaya government customers, please refer to the MUDG (Military Unique
Deployment Guide) to obtain the solution configuration description used in the
JITC test labs for the description of CM, gateways and phones.
 Identity certificates must be packaged in PKCS12 file formats in order to be
properly downloaded onto Avaya Aura products
– If the third party certificate is being created using an OpenSSL tool kit on some 3 rd
party PC or workstation, the following command line options are recommended:
• openssl pkcs12 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -out
cm.pfx -inkey cm.key -in cm.crt -certfile cm.crt -passout pass:1adg
– If the 3rd party PC or workstation has its OpenSSL application configured to operate
in FIPS-mode, then subsequent usage of the OpenSSL toolkit to generate CSR
signing requests will automatically include proper encryption options, including a
random number generator compatible with the NIST SP 800-90.
– This 3rd party host workstation may support OpenSSL version 0.9.8e or newer.
• We would recommend operation with OpenSSL version 1.0.1 as a minimum.
 Trust Chains {includes both the CA Root and the Trusted chain (if there are
intermediate CA’s)} should be presented as a “.pem” file.
 It is strongly recommended that all certificates be signed with a 2048 bit RSA
and a SHA2 hash algorithm.
Operation of H.323 phone for Initial Registration and
TLS connection establishment
Operation of H.323 phone for Initial Registration and TLS connection

establishment
 (With reference to the figure on the next page), the H.323 station shall complete
the gatekeeper discovery phase with the Gatekeeper Request/Confirm exchange.
a) The H.323 station shall open a TCP socket
b) The H.323 station shall then issue a ClientHello to initiate TLS Connection
establishment.
c) The registration will be completed securely within the TLS pipe with the
Registration Request/Confirm.
d) Then the H.225/Q.931 exchange will complete the Signaling channel
establishment.

Message Sequence for Initial Registration and
TLS Connection Establishment
Non-TTS Phones (Existing R6.3-FP4) & TTS-Phones (R7.0.1)
Function Messages Protocol
Endpoint Gatekeeper
(CM)
Discovery Gatekeeper Request
UDP port 1719
(for non-TTS H.323 Gatekeeper Confirm H.225/RAS

Phones)
Open TCP socket

TCP port 1300
ClientHello
ServerHello
TLS Connection
Certificate Exchange TLS
Establishment
Station is the “Client” Cipher Exchange
Registration Register Request

TCP port 1300
(for H.323 stations) Register Confirm H.225/RAS
Signaling Channel SETUP FastStart H.225/

TCP port 1300
CONNECT Q.931,CCMS
Establishment
Call Information H.225/

TCP port 1300
Call Ready Phase Q.931,CCMS

Operation of H.323 phone for Network Outage
/Duplicated PE Server Interchange
 Upon CM re-opening the TCP socket, the H.323 station shall perform the
following actions:
a) The H.323 station shall then issue a ClientHello to initiate TLS Connection
establishment.
b) The phone sees the TTS flag and understands that it does not have to perform a
re-registration.
c) Then the H.225/Q.931 exchange will complete the Signaling channel
establishment.

Message Sequence for Re-establishment after Network
Outage /Duplicated PE Server Interchange
for TTS Stations (new R7.0.1)
Function Messages Gatekeeper Protocol
Endpoint (CM)
NOTE:CM has the
TTS reg. information.
Discovery/Registration No new registration
H.225/RAS
required
(for all TTS H.323 stations)
Open TCP socket TCP port 1300 Server Interchange; or

automatic after network
ClientHello outage (these are the CM
TLS Connection triggers):
ServerHello
Establishment -Incoming call
Certificate Exchange
Station is the “Client” -Station RRQ (KeepAlive) UDP 1719
-Station ARQ (offhook) UDP 1719
Cipher Exchange
TLS
SETUP FastStart
TCP port 1300
Signaling Channel CONNECT H.225/Q.931,
Establishment H.245, CCMS
Call Information H.225/Q.931,

TCP port 1300
Call Ready Phase H.245, CCMS
Communication Manager Administration

CM Port Matrix
 The Customer’s Security Administrator must enable the following ports to support TLS links
to gateways and H.323 phones:
 TCP port 1300 is used for the TLS signaling connection to the H.323 phones.
 TCP port 2944 is used for the TLS connection to tunnel the H.248 control channel between CM
and the G430/G450 gateways.

CM Administration
-Summary of Configuration
 The Customer’s Security Administrator needs to perform the following tasks on the CM
server to prepare for deployment on a government customer site:
 Install CM software load CM R7.0.1 (or later)
 Get a 3rd party host certificate set (CM Identity cert & Trusted Root CA cert which
signed the Gateway Identity cert & Trusted Root CA cert which signed the H.323
Phone’s Identity cert)
 This is required for both the Communication and the Web Identity Cert repositories.
 Check that the CM SAT’s System Capacity form’s ‘H.323 Stations via TLS’ has
sufficient capacity to support those customer H.323 phones that need to operate in
TLS mode.
 Check that the CM SAT’s Security-Related System Parameters form so that the field
‘TLS Mutual Authentication’ is administered to “yes” on a system-wide basis.
 Check that the CM SAT’s IP-Network-Region form (covering where the phones are
located) so that the field ‘H.323 Security Profile’ is set to “H323TLS”.
 Configure the CM SAT’s Media Gateway form
 Link Encryption Type
 Mutual Authentication (recommended to be set to yes)

CM Administration
-FIPSMode Configuration (if desired)
 The CM’s CLI command to enable and disable FIPSMode is “fips_mode”.

– The Security Administrator that can execute this command are any users that belong to the
“susers” group.
• init, inads, craft
– To enable FIPSMode, execute the “fips_mode enabled” command
• The Security Administrator will be prompted for a “y/n” and then the CM server will reboot
automatically
– To disable FIPSMode, execute the “fips_mode disabled” command
• The Security Administrator will be prompted for a “y/n” and then the CM server will reboot
automatically

CM Administration
-Web Server Certificate Management
(for Third Party Hosted Certs)
 Once the third party certificates have been created/located, the customer needs to copy
the rootCA.pem certificate and the Identity certificate into the /var/home/ftp/pub directory
on the CM server.
 Then go to the ‘Trusted Certificates’ menu item on the SMI web page and select “Add”.
 Note 1: Please note that at any stage of the following pages, that clicking on the “Help”
button will resolve your questions.
 Note 2: for simplicity, on the following pages we have presented the example of loading
the Communication Manager Identity certificate. The customer’s Security Administrator
could check the “Web” box as well and load this Identity certificate into both the “C and W”
repositories. The CM Trust CA store should be loaded with the CA Trust chain that is
required for each of the TLS applications.

CM Administration
-Downloading a CA and Identity Certificate into CM Server
 Go to Administration/Server > Miscellaneous > Download Files and browse to the directory on
your computer where you have stored the certificate pair. Then select “Download”
 The files will be downloaded into the /var/home/ftp/pub directory on this CM server.

CM Administration
-Web Server Certificate Management (continued)
 Type in the name of the CA.pem file and select “open”.

CM Administration
 Type a desired filename for the stored CA file and select “Communication Manager” as the
desired CA application repository. Then select “Add”.

CM Administration
 After completion of the file store, the following screen will show the status of the CM’s CA
repository (second line for this example). Starting in R7.1, CM does NOT have to be restarted for
this CA to take effect.
 Note: When updating CM’s Trust Store, please consider removing old entries that are not in use.

CM Administration
 For Identity certificates, select “Server/Application Certificates .
 Enter the name of the PKCS12 file stored in /var/home/ftp/pub and enter the password for that file and
select “Open”.

CM Administration
 You will see the Identity certificate listed. Then select the Communication Manager repository and press
“Add”.

CM Administration
 After completion of the file store, the following screen will show the status of the CM’s Identity
repositories (see first entry for this example). CM does not have to be restarted at this point!

Use the SMI ‘Copy’ button to Copy Identity Cert
over to Another Application Repository
 If you loaded an Identity certificate into the “C” (communication repository) and
your need to use this same Identity certificate to be loaded into “W” (web
repository), use the “Copy” button as follows:
1) Go to the ‘Trusted Certificates’ SMI page (as shown on slide # 27) and select
• the CA trusted chain certificate file which you wish to copy
• Then select “Copy”.
• When prompted, select the “W” trusted repository
• At the conclusion of this action, check to see that this Trusted Cert now shows ‘Trusted by W’.
2) Go to the “Server/Application Certificates” SMI page (as shown on slide #30) and
select:
• The Identity certificate file which you wish to copy.
• Then select “Copy”.
• When prompted, select the “W” trusted repository
• At the conclusion of this action, check to see that this Identity Cert now shows ‘Installed in W’.

Policy Rules for TLS Minimum Version on CM
- New feature for R7.1
The Minimum TLS Versions feature will provide a method for the System
Administrator to specify TLS version usage for the following connection types.
(See next slide for SMI page).
 System Management (SMI) pages (Apache web services)
 CM Duplication link (Communication services)
 FileSync connection (Communication services)
 CM Signaling for SIP trunks, H.248 gateways, H.323 phones, AES)
Policy rules:
• Pull-down window offers choices of TLS versions (1.0, 1.1, 1.2).
• Must restart CM after a change to SMI page.
• Default is to use “TLS Version 1.0” in CM registry file.
• CM Signaling currently affects all trunks. So, if a given peer can only support
version 1.0, Administrator must set all to operate with TLS version 1.0.
o Desirable enhancement (post R7.1) would change Signaling-Group SAT form to allow
override on an individual trunk group basis.
CM Administration via Server Access SMI Page

CM Administration
-System Capacity (for H.323 station support of TLS)
display capacity Page 11 of 13

SYSTEM CAPACITY
CONCURRENT REGISTRATION COUNTS

Currently System
Used Available Limit
-----------------------------
H.323 Stations: 5000 13000 18000
IP Stations in TTI State: 0 - -
IP Attendant Consoles: 0 0 0
Remote Office Stations: 0 0 0
Unauthenticated H.323 Stations: 0 0 0
AES Server Licensed IP Stations: 0 - -
IP PORT USAGE COUNTS

Total IP Station Ports: 5000 54900 95414
IP Station Ports Used By

Administered IP Stations and Attendants: 5000 - -
Softphone Enabled on Station Form: - - -
Unnamed Registrations (TTI IP phones): 0 - - New
H.323 Stations via TLS: 2000 0 2000 limits
– Large CM Platform => 18000 H.323 phones

– Medium CM Platform => 2400 H.323 phones
– Small CM Platform (S8300x) = > 1000 H.323 phones
CM Administration
-Station Form’s Mutual Authentication
 For each station user, the ‘Require Mutual Authentication’ parameter on the SAT station form must be
configured to “yes” to direct that “Mutual Authentication” is enabled.
– This means that the TLS Server (CM) and the TLS Client (96x1 H.323 phone) must both
exchange Identity certificates and CM shall authenticate the other side’s certificate.
– For staging, if the customer does not load an Identity certificate on the individual phone, then this
field can be turned to “no”. CM will not expect a certificate to be shared from the phone.

CM Administration
-IP Network Region
display ip-network-region 1 Page 3 of 20

IP NETWORK REGION
INTER-GATEWAY ALTERNATE ROUTING / DIAL PLAN TRANSPARENCY

Incoming LDN Extension:
Conversion To Full Public Number - Delete: Insert:
Maximum Number of Trunks to Use for IGAR:
Dial Plan Transparency in Survivable Mode? n
BACKUP SERVERS(IN PRIORITY ORDER) H.323 SECURITY PROFILES

1 1 H323TLS
2 2
3 3
4 4
5
6 Allow SIP URI Conversion? y
TCP SIGNALING LINK ESTABLISHMENT FOR AVAYA H.323 ENDPOINTS

Near End Establishes TCP Signaling Socket? y
Near End TCP Port Min: 61440
Near End TCP Port Max: 61444
 For all customers, the IP Network Region form contains a parameter that governs H.323 phone
registration within a defined network region.
– Change the “H.323 Security Profile” parameter to “H323TLS to enable the use of TLS connections
for all H.323 phones which exist in this defined network region.

CM Administration
-Media Gateway Form
add media-gateway next Page 1 of 2

MEDIA GATEWAY 3
Type: g450
Name:
Serial No:
Link Encryption Type: TLS-only
Network Region: Location: 1
Site Data:
Recovery Rule: none
Registered? n
FW Version/HW Vintage:
MGP IPV4 Address:
MGP IPV6 Address:
Controller IP Address:
MAC Address:
Mutual Authentication? y
 The ‘Link Encryption Type’ should be administered to “tls-only”.

 The ‘Mutual Authentication’ field supports the keywords:
– yes
– no
 The security administration should select “yes” to request that both the CM server (as the TLS host) and
the gateway (as the TLS client) have to exchange valid Identity certificates.
 Note that if “no” is selected and no Identity certificate is loaded in the gateway’s h248 application
directory; then CM will accept a TLS registration without the gateway having to offer its Identity
certificate. This is handy when doing staging and when the craft do not have the gateway certificates.

96x1 H.323 Phone Administration

 The Customer’s Security Administrator needs to configure the ‘Settings’ file on the phone
Utility Server
 Install 96x1 Phone software load 6.6.2 (Load 27 or greater)
 Get a 3rd party host certificate set (Phone Identity cert & Trusted Root CA cert which
signed CM’s Identity cert)
 CRAFT UI option shall be set to ON (by default).

-Summary of Configuration (security)
Utility Server
 Update the Settings file with the following configuration:
 FIPS_ENABLED should be set to “0”.
 This product Has not been formally FIPS certified. For the TLS sessions, CM (in its role of TLS server) will
govern the cryptographic algorithms used. If CM’s OS is set to FIPS mode, it will ensure that FIPS
approved algorithms are deployed.
 TO operate in a FIPS compliant mode FIPS_ENABLED should be set to “1”
 While the product has not been FIPS certified, it has “inherited” general compliance because the design
has integrated OpenSSL FIPS Object Module 2.0.9 (FIPS 140-2 validated cryptographic module per NIST
Certificate 1747) for Linux embedded platform.
 PROCSTAT should be set to 0 (its default value) so that static IP addresses can be
configured.
 PROCPSWD should be set via CM administration to a non-default value.

-Summary of Configuration (security continued)
Utility Server
 PKCS12URL should be set to the URL of a PKCS #12 file containing an identity certificate for
the telephone and the corresponding private key. This is normally done in a staging
environment before the telephone is deployed.
 TRUSTCERTS should be set to a list of files that contain certificates to be used as trust points
for the establishment of TLS connections, including 802.1X EAP methods that use TLS.
 The files for each of the Trust CA cert chains must be stored as “.txt” file type
 TLSSRVRVERIFYID should be set to 1 to direct the phone to validate the identity of the TLS
server (such as CM) is checked against the Common Name in its Identity certificate.
 This parameter requires that the value of “MCIPADD” will match the SubjectAltName field of the peer’s
(CM) Identity certificate.
 MCIPADD can be either an IP address or a hostname.
 Any change to a PKCS12 file (Identity cert) or Trusted Certificate files requires a change in the filename to
enforce the phone to download the update to the correct phone cert repositories after a reboot action.
 CERT_WARNING_DAYS should be set to the number of days before the expiration of a

trusted certificate’s valid lifetime at which a syslog/log messages shall be sent / created.
 SERVER_CERT_RECHECK_HOURS should be set to support the time period for periodic

tests for certificate expiration and for certificate revocation.
 Please review the OCSP parameters slide.
-Summary of Configuration (Security continued)
Utility Server
 TLS_SECURE_RENEG should be set to 1 to terminate a TLS session if the peer does not
support secure renegotiation.
 TLSSRVR should be set to the IP address of a file server that can download configuration files
via HTTPS.
 TPSLIST should be set to null (its default value) because the Push server does not support
TLS or IPv6. VVoIP STIG request to disable HTTP servers if no authentication is done
 AUTH should be set to 1 so that configuration files will only be downloaded via HTTPS.
 HTTPSRVR should be set to the IP address of a file server that can download software files
via HTTP.
 OPSTAT should be set to 101 so that configuration information is not displayed.

-Summary of Configuration (Security continued)
Utility Server
 SNMPSTRING should be set to null (its default value) since 96x1 H.323 phones do not
support SNMPv3.
 SSH_ALLOWED should be set to 0 to keep SSH disabled.
 NVVPNMODE should be set to 0 (its default value) because the IKE/IPSec implementation
does not meet some requirements (5.4.6.2.3, 1.c(1)(c)ii, 1.c(1)(c)viA), VPN is not supported in
FIPS mode, and VPN does not support IPv6.

-Summary of Configuration (General IP Features)
Utility Server
 SLMSTAT should be set to 0 (its default value) because the SLA Monitor Agent does not
support IPv6.
 VLANSEP should be set to 1 (its default value) and VLANSEPMODE should be set to 1 to
enable VLAN separation. In this mode the PC cannot reach the phone. Note that the network
switch must be configured to leave 802.1Q tags on frames forwarded to the telephone and PC
(for both data and voice VLANs) so that the switch in the telephone can enforce VLAN
separation.
 L2QVLAN shall be configured to the voice VLAN. L2QVLAN shall be set to value other than 0
or PHY2VLAN.
 L2Q shall be set to a value of 0 (auto) or 1 (Tagging). The phone will try to get IP address from
DHCP server on voice VLAN and if succeeded the phone will send all the rest of the packets
tagged on voice VLAN.

-Summary of Configuration (General IP Features continued)
Utility Server
 PHY2VLAN should be set to the data VLAN (native VLAN) to assign this VLAN to untagged
packets from the PC or forward only tagged packets from PC with PHY2VLAN only. Tagged
packets from PC on VLANs other than PHY2VLAN will be blocked. PHY2VLAN shall be set to
value different than 0 or L2QVLAN.
 SSO_ENABLED should be set to 0 (its default value) because it does not support IPv6.
 VPNPROC should be set to 0 as VPN is not supported in FIPS mode.
 Console port shall NOT be enabled in the DEBUG menu under CRAFT menus since there is
no session timeout or authentication supported on the console port once enabled.
 802.1x shall be disabled (DOT1XSTAT=”0”) since 802.1x is not supported in FIPS mode.
 WMLIDLEURI shall be configured to null string (default) since the “VvoIP STIG” requires
disable of browsers.

-Summary of Configuration (General IP Features continued)
Utility Server
 WMLHOME shall be configured to null string (default) since the “VvoIP STIG” requires disable
of browsers.
 AUTOANSSTAT shall be configured to 0 (by default) since the “VvoIP STIG” request to
disable auto answer feature.
 GUESTLOGINSTAT shall be disabled (0, default) since “VvoIP STIG” requests to disable the
guest login feature if not activated for certain users only.
 VUMCIPADD shall be null string (default) since “VvoIP STIG” requests to disable the visiting
login feature if not activated for certain users only.

-Summary of OCSP Configuration
 Update the Settings file with the following configuration if On-Line Certificate Status
Protocol (OCSP) is to be employed for certificate revocation checking:
 OCSP_ENABLED should be set to 1 so that OCSP will be used to check the revocation status
of received certificates .
 OCSP_URI_PREF should be set to 1 if OCSP requests should be sent to the URI specified by
OCSP_URI before trying a value provided in the OCSP field of the Authority Information
Access (AIA) extension of the certificate being checked, or it should be set to 2 if OCSP
requests should be sent to the URI specified by the value provided in the OCSP field of the
Authority Information Access (AIA) extension of the certificate being checked before trying the
URI specified by OCSP_URI.
 OCSP_URI should be set to the URI of the OCSP responder if one is to be used that is not
specified in the certificates to be checked.
 OCSP_ACCEPT_UNK should be set to 1 for a certificate to be trusted if its revocation status

cannot be determined, i.e., if the status is unknown.

-Summary of OCSP Configuration (continued)
 Update the Settings file with the following configuration if On-Line Certificate Status
Protocol (OCSP) is to be employed for certificate revocation checking:
 OCSP_NONCE should be set to 1 (the default) so that a nonce will be included in OCSP
requests.
 OCSP_TRUSTCERTS should be set to a list of files to be downloaded as a separate trusted

certificate repository for the OCSP Trusted Responder Model that contains certificates to be
trusted when the OCSP response is not signed by a certificate issued by the same CA that
issued the certificate that is being checke.d

-Summary of SCEP
 SCEP (Simple Certificate Enrollment Protocol) was originally developed by Cisco and
Verisign.
 This allows the phone to automatically sends a certificate signing request to a SCEP server
 A summary of this certificate enrollment is:
 Request/response model base on HTTP.
 Employs RSA-based cryptography.
 Uses PKCS#10 as the certificate request format.
 Uses PKCS#7 in order to convey cryptographically signed/encrypted messages.
 Supports asynchronous granting by the server and regular polling by the requester.
 Has limited Certificate Revocation List retrieval support.
 Does not support online certificate revocation (must be handled by another process).
 Requires the use of a challenge password field within the signing request, which is shared
between the server and the requesting phone.

-Summary of SCEP (continued)
 Update the Settings file with the following configuration if the phone Identity Certificate
is to be created automatically by a SCEP server
 MYCERTURL should be set to the IP address for the SCEP server.
 This may be a Windows server running “Active Directory Certificate Services”
 This may be an Avaya System Manager with SCEP configured.
 MYCERTCN should be set to “$SERIALNO” to use the serial number of the phone as the
client side identification.
 MYCERTDN should be set to the geographic identity of the customer’s domain

 For example: /C=US/ST=CO/L=Thornton/O=Avaya
 MYCERTAID is optional and should be configured it you want someone other than Microsoft to
act as the CA (for case of using a Windows application).
 MYCERTKEYLEN should be set to “2048” to direct that RSA2048 be the key length for
forming the digital signauture.
 MYCERTRENEW should be set to “90” to identify the periodicity of renewal.

-Summary of SCEP (continued)
 Update the Settings file with the following configuration if the phone Identity Certificate
is to be created automatically by a SCEP server
 MYCERTWAIT should be set to “1” to direct that the SCEP protocol request will wait until
either an Identity Certificate is returned or an SCEP Request message is received.
 SCEPPASSWORD should be set to “$SERIALNO”.

 We think that this is the easiest method for unique identification of the phone.

G430/G450 Gateway Administration

-Philosophy
 The gateway has a command line interface (CLI) that supports a set of new commands for the enabled
of a FIPS certified mode of operation.
 The gateway’s control module “Gateway.o” and the maintenance module “Maintenance.o” will enforce
the policies for operation while the gateway is in FIPs mode.
 The following policies will be enforced while in FIPS mode”
1. The two choices of H.248 establishment will be:
a) TLS ( UDP port 2944)
b) None (UDP port 2945)
2. The local survivability feature, SLS, will be disabled since SLS does not currently support the use
of encryption over the media to the co-located IP phones nor does it support TLS over the H.323
control link to the co-located IP phones.
3. The administrator is advised to disable Telnet.
4. The gateway shall enforce that when CM sends a media connection request, that it only be using
the SRTP encryption modes (SHA1-AES128-80, SHA1-AES128-32, SHA2-AES256-80, SHA2-
AES256-32 or None). Otherwise the call request will be denied.
 The following pages review the administration steps, with detail paid to the CLI commands
for the gateways.

 The Customer’s Security Administrator needs to perform the following tasks on the gateway
to prepare for deployment on a government customer site:
 Install Gateway software load 38.15.0 (or greater)
 Get a 3rd party host certificate set (Gateway Identity cert & Trusted Root CA cert which
signed CM’s Identity cert)
 Follow the follow configuration steps (refers to gateway CLI commands:
 Set the certificate management options for cert validation with the ‘certificate-options’
command
 Configure the ‘set ip-address-map’
 Use the ‘copy scp root-ca’ command to download the Trusted Root CA certificate(s)
 Use the ‘copy gw-identity-cert’ command to download the Gateway Identity certificate
 Optionally employ the copy commands to download the SLA Monitor certificate set
 Configure the ‘set http proxy’ command if the enterprise requires a proxy firewall
 Use the ‘show crl’ and ‘erase crl’ commands to cleanup the CRL list which gets built by the
gateway

-Enable/Disable FIPS Mode
 The gateway’s CLI for the FIPS mode command is as follows

• set fips-mode {enable | disable }
• Use the ‘disable’ option to place the gateway into a standard mode of operation.
• Use the ‘enable’ option to place the gateway into a FIPS mode of operation.
• show fips-mode
• This command will show the state of the FIPS mode configuration
• Example:
G450-gloin-020(develop)# show fips

FIPS Mode: Enabled
FIPS Tests: Passed
DSP Cryptography Test: Passed
DSP Hash Integrity Test: Passed
DSP PRNG Test: Passed
MGP Cryptography Test: Passed
MGP Hash Integrity Test: Passed
MGP PRNG Test: Passed
G450-gloin-020(develop)#
G450-gloin-020(develop)# show sls
SLS is : disabled
Note: SLS is not supported while FIPS mode is enabled.

-MGC List
 The media gateway’s CLI command for the Media Gateway Controller (MGC) list has been expanded to
include the new encryption option of ‘TLS’.
 Remember that in the gateway’s FIPS mode, that the only two permitted choices are ‘TLS’ and “None’.
The gateway will attempt to register by going to the first member of the MGC list and trying to register
with first ‘TLS’ and then secondly with ‘none’. It will repeat this three times and then move to the next
host H.248 controller in the MGC list.
• show mgc
• This command will show the state of the FIPS mode configuration
• Example:
G450-gloin-200(develop)# show mgc
CALL CONTROLLER STATUS

-------------------------------------------
Registered : YES
Active Controller : 10.129.176.47
Controller SW Version : R017x.00.0.415.0
H248 Link Status : UP
H248 Link Encryption : TLS
H248 Link Error Code : 0x0
PRIMARY MGC HOST, Primary Search Time : 1 min(s)

IPv4 Address IPv6 Address
-------------------- ----------------------------------------------
10.129.176.47 -- Not Available --
SECONDARY MGC HOST

IPv4 Address IPv6 Address
-------------------- ----------------------------------------------
-- Not Available -- -- Not Available --
sls disabled

-Set Link-Encryption command
 The media gateway has a new CLI command under the “root” login that will provide the ability for the
customer’s Security Administrator to define the policy rules for the client offer for TLS version.
• set link-encryption h248reg {protocol} <yes | no>
o Where {protocol} = <all | tls | tls1.2 | tls1.1 | tls1.0 | ptls | unencrypted>
• set link-encryption sla {protocol} <yes | no>

o Where {protocol} = <all | tls | tls1.2 | tls1.1 | tls1.0>
• The following shall be the default options in non-FIPS mode:

set link-encryption h248reg tls-1.2 yes
set link-encryption h248reg tls-1.1 no
set link-encryption h248reg ptls yes
set link-encryption h248reg unencrypted yes
set link-encryption sla tls-1.2 yes

set link-encryption sla tls-1.1 no

-Set Link-Encryption command (continued)
customer’s Security Administrator to define the policy rules for the client offer for TLS version.
• The following shall be the default options in FIPS mode:
set link-encryption h248reg tls-1.2 yes
set link-encryption h248reg ptls no
set link-encryption h248reg unencrypted no
set link-encryption sla tls-1.2 yes

Note that “ptls” cannot be enabled while in FIPS mode.

• Show line-encryption
# show link-encryption h248reg
TLS : yes
TLS 1.2 : yes
TLS 1.1 : no
TLS 1.0 : no
PTLS : yes
Unencrypted : yes
# show link-encryption sla
TLS : yes
TLS 1.2 : yes
TLS 1.1 : no
TLS 1.0 : no

-Certificate-Options command
customer’s Security Administrator to define the policy rules for the verification of the received Server’s
Identity certificate.
• Certificate-options {this is a new command with a two-level context}
o set validate-common-name{yes | no}
• Where “yes” operates to validate on commonName of received cert and to reject TLS
connection on a failure. Validation uses the field content of the IP-Map-Address command.
o set validate-alternate-name{yes | no}
• Where “yes” operates to validate on subjectAlternateName of received cert and to reject
TLS connection on a failure. Validation uses the field content of the IP-Map-Address
command.
o set validate-expiration { initial connection | always | never}
• “initial connection” is the recommended choice for most customers. This is the default.
• “always” is the choice for JITC testing to conform to the UCR dictate to release H.248
connection upon event.
o set crl-http-validation <none | best-effort | mandatory>
• Where “best-effort” or “mandatory” operates to verify certificate revocation by using the url
inside of the cert to do a search of the CDP site(s).
• Default is best-effort
• CRLs will be refreshed per the setting of the crl-refresh-interval

-Certificate-Options command (continued)
o set crl-refresh-interval <days>

• Range is from 0 to 90 days
• Default is 7 days
• If “0” is entered, no crl refresh shall be performed.
o set ocsp-validation < none | best-effort | mandatory>
• Where “best-effort” or “mandatory” specifies that the OCSP client request should be
employed for validating the hose server application cert.
• Default is best-effort
• Note: If both CRL validation and OCSP validation are enabled, the gateway’s certificate
management software shall always use the OCSP technique first.
 If the OCSP responder replies with “unknown” or “error” or if the host application can
not be reached, then the CRL method will be used
o set ocsp-url <app> <uri-address>
• Where <app> is h248reg to specify the cert repository.
• Where <url-address> is the ip address associated with the OCSP host server.
 May be either IPv4 or IPv6
o set ocsp-ulr-priority {local|certificate}

• This directs whether the certificate’s URI address or whether the local address set with the
“ocsp-uli” command is to be used.

-Certificate-Options command (continued)
o show certificate-options
show certificate -options:
Certificate Options
====================================
Validate Alternate Name: no
Validate Common Name: yes
Validate Expiration: initial-connection
CRL HTTP Validation: yes
CRL-Refresh-Interval: 14
OCSP Validation: no
OCSP Local URL:
OCSP URL Precendence: certificate

- IP-Address-Map command
 The gateway shall support a new CLI command that will allow the customer to administer a mapping
table to help translate string names into ‘IPv4’ or ‘IPv6” addresses. The gateway’s Certificate
Management uses this to assist in the resolution of commonName field of the server’s Identity Cert.
 The gateway’s command is as follows:
• set ip-address-map <name> <ip>
• where <name> is the string name that is a FQDN, URI domain name, or any string name.
• <ip> is the IP address that corresponds to the ‘name’ field.
• If an IP address is used as the “commonName” then you must still input the IP address in the
second parameter.
• Example
set ip-address-map “ukbbcomacm01.ukbb.intern” 10.130.27.23
set ip-address-map “10.130.27.20” 10.130.27.20
• To remove an entry: erase ip-address-map <name-index>

• where <name-index> refers to a decimal index (1 to 50) in a table used by the show
command.
• Example: erase ip-address-map 3
Index #3
how.about.athird
189.123.253.159
This is the entry you will erase - do you want to continue (Y/N)? y

- IP-Address-Map command (continued)
• show ip-address-map
• This command will show the administered mapping entries;
• Example:
Index #1
numero.uno
145.176.123.087
Index #2
the.second.one
2300:4567:9876:4837:2345:9834:2345:3825

- Root CA Command Set
 The gateway supports a new CLI command group (copy, show, erase) that supports the download of
one or more Root-CA certificates from a host server.
• Note that the signing authority for CM may be different from the signing authority for the gateway.
• In complex security enterprise topologies, there may be multiple CMs, each of which has a different signing
authority.
• This feature supports two application directories in which Root-CA certificates may be placed (h248reg and sla)
• H248reg designates the directory to place Root-CA certificates for validation of link establishment to CM.
• SLA designates the directory to place the single Root-CA certificate used for validation of link establishment to
the SLA Monitor server for diagnostic purpose.
• The copy mechanism is the SCP (secure copy)
• Copy scp root-ca <app> <filename> <ip>
• where <app> is the application directory in which the cert is to be stored.
– Choices are h248reg or sla.
• <filename> is the full file path useable be an SCP login on the target host server.
• <ip> is the IP address of the target host server which owns a copy of the file to be loaded.

- Root CA Command Set (continued)
 The”index of each line above can be used as a “handle” to identify the certificate. If one desires more
detail about a certificate, supply the index of the cert on the command line.
• show root-ca <app>
• Example:
G450Qu-018(super)# show root-ca h248reg 1
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DoD JITC Root
CA 2
Validity
Not Before: Jul 15 03:31:31 2005 GMT
Not After : Jul 4 03:31:31 2030 GMT
Subject: C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DoD JITC
Root CA 2
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b4:48:ca:63:29:78:43:a1:94:65:ac:9c:0a:d2:
77:2b:83:30:df:2f:b3:92:d4:cd:ee:97:8d:ea:47:
56:05:ea:04:f4:31:d8:05:9b:f7:1d:81:38:87:e3:
4a:a0:88:ca:5f:06:38:1c:a7:24:bc:1a:c8:66:29:
51:12:46:49:c9:df:2d:93:12:5e:bb:7a:48:73:e8:
7f:68:27:97:e8:6a:03:bd:52:b1:bc:3e:8e:d3:3c:
b4:00:e5:7e:06:93:db:59:28:d6:26:26:f3:c9:da:
9a:56:f7:15:16:d3:cf:81:b6:70:1b:07:21:a0:f4:
0e:19:03:d8:35:6d:3d:42:61:5b:86:9b:56:24:d0:
--type q to quit or space key to continue--

- Root CA Command Set (continued)
 The”index of each line above can be used as a “handle” to identify the certificate in order to erase
(delete) the Root-CA certificate referenced ty the ‘index’.
• erase root-ca <app> <index)
• Example:
G450Qu-018(super)# erase root-ca h248reg 1
Done!
G450Qu-018(super)# show root-ca h248reg
Index Issued To Issued By Expires
1 DOD JITC CA-27 DoD JITC Root CA 2 Mar 16 00:00:00
2017 GMT
Done!

- GW Identity Certificate Command Set
 The gateway supports a new CLI command group (copy, show, erase) that supports the download of
the Gateway’s Identity certificate from a host server.
• Note that the command must be run as root and will prompt the user for a login/password on the
remote host system.
• The file to be installed must be in PKCS #12 format.
• The encapsulated certificate must contain at least the Identity certificate, and if encoded in PEM
format, it may have an appended trust chain as well.
• When trust chains are embedded, the chain elements must be ordered from low-to-high trust, and
the Identity certificate must be the first element in the file.
• copy scp gw-identity-cert<app> <filename> <ip>
• <filename> is the full file path useable be an SCP login on the target host server.
• <ip> is the IP address of the target host server which owns a copy of the file to be loaded.
• Example: G450Qu-018(super)# copy scp gw-identity-cert h248reg
/home/ldg/jitc_1.p12 172.16.1.252
Username: ldg
Password:
Enter PKCS #12 password:

Done!
G450Qu-018(super)#

- GW Identity Certificate Command Set (continued)
 The gateway supports a show command to provide a display dump of the contents of the Gateway’s
Identity certificate.
• show gw-identity-cert<app>
• Example:
G450Qu-018(super)# show gw-identity h248reg

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 13827 (0x3603)
Issuer: C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DOD JITC CA-27
Validity
Not Before: Nov 13 20:18:14 2013 GMT
Not After : Nov 13 20:18:14 2016 GMT
Subject: C=US, O=U.S. Government, OU=DoD, OU=PKI, OU=CONTRACTOR,
CN=Avayacert1
Public-Key: (2048 bit)
Modulus:
00:d7:59:7e:f6:a8:59:7d:57:5f:f8:f0:31:8b:34:
d0:d6:b3:3b:75:5c:8e:ca:0e:02:48:02:f5:42:b1:
c9:41:74:fc:be:f6:fc:9c:93:45:c2:f3:72:7a:da:
5e:dd:e3:4d:a5:b4:76:ab:34:4e:a0:38:ad:6c:d3:
24:2d:51:f2:49:33:ad:16:64:d8:7a:49:2d:9a:bf:
52:8e:4c:37:11:2b:46:11:f2:c3:39:cf:1f:86:d9:
93:e6:d4:7e:fc:fb:03:1e:82:26:08:4f:43:80:7e:
df:2b:2f:4e:f7:40:82:0f:75:c5:87:ee:f4:6c:81:
--type q to quit or space key to continue--

- GW Identity Certificate Command Set (continued)
 The Gateway Identity Certificate Erase command allows the removal of the Identity Cert for a given
application (that supports a TLS connection).
• erase gw-identity-cert <app>
• The enumeration choices for “app” are “h248reg” and “sla”
• Example:
G450Qu-018(super)# erase gw-identity-cert h248reg
Done!

- HTTP Proxy command
 The CRL lookup process may have to access the Internet to access a CDP site to check whether a
certificate has been revoked. If the customer’s enterprise requires a proxy firewall to access the
Internet, then this feature is recommended.
• set http proxy <ip> [ <port>}
• Where <IP> is the ip address (or hostname) of the proxy server
• <port> is the optionally specified UDP port.
• To disable the feature, ‘set http no-proxy’.
• show http
• This command will show the state of the http proxy
• Example 1:
HTTP Proxy Host: proxyhost
HTTP Proxy Port: 8000
• Example 2 (when no-proxy is administered:
No Proxy

- CRL List Command Set
 The gateway supports a new CLI command group (show, erase) that supports the ability to display the
CRLs that have been downloaded into the gateway and to erase unnecessary CLRs which have been
download as part of certificate management.
• Show crl [ <index> ]
• <index> refers to an index for this entry in a table (as provided by the ‘show crl’ command.
• All displayed timestamps are GMT-relative
• Example:
This example shows 7 CRLs which have been installed on the gateway. Line #5 is a legal
example of a CRL which has no ‘Issuer Common Name’.
Line #6 displays a file which is not a CRL and may be safely removed.
G450Qu-018(develop)# show crl
Index Issuer-Common-Name This-Update Next-Update Size

1 Akamai Subordinate CA 3 Apr 11 17:26:32 2013 May 11 17:26:32 2013 23602
2 Thawte SSL CA Nov 4 21:00:48 2013 Nov 14 21:00:48 2013 367038
3 COMODO SSL CA Nov 4 22:10:06 2013 Nov 8 22:10:06 2013 97416
4 DoD Interoperability Ro Oct 10 13:49:16 2013 Nov 14 13:49:16 2013 564
5 Apr 11 22:47:23 2013 Apr 11 22:47:23 2014 429
6 bad format CRL file ? ? 5
7 GlobeSSL CA Nov 4 22:08:10 2013 Nov 8 22:08:10 2013 5690
Done!

- CRL List Command Set (continued)
• Issuing ‘show crl’ with the <index> argument results in a display of the contents of a given
CRL.
• Example:
G450Qu-018(super)# show crl 2
Certificate Revocation List (CRL):
Version 2 (0x1)
Issuer: /C=US/O=Thawte, Inc./CN=Thawte SSL CA
Last Update: Nov 4 21:00:48 2013 GMT
Next Update: Nov 14 21:00:48 2013 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:A7:A2:83:BB:34:45:40:3D:FC:D5:30:4F:12:B9:3E:A1:01:9F:F6:DB
X509v3 CRL Number:

2579
Revoked Certificates:
Serial Number: 01038A9B1741AB89893CC4D6BBE9A2BF
Revocation Date: May 14 20:21:36 2012 GMT
Serial Number: 0104DCE1C52D255706C673013E00F42E
Revocation Date: Sep 9 20:14:14 2013 GMT
Serial Number: 0108A02C5DFBBCD825D03FF04700390D
Revocation Date: Nov 19 21:03:13 2012 GMT
Serial Number: 010A9665678EF1A94BF78B8377902BE0
Revocation Date: Aug 25 11:02:22 2012 GMT
Serial Number: 010FD0393A409420B582A72F6FDBE7AB
Revocation Date: Sep 25 11:43:37 2013 GMT

- CRL List Command Set (continued)
• Issuing ‘erase crl’ with the <index> argument results in the removal of an unwanted CRL from
the list that has been built the gateway’s Certificate Management softward
• Example of ‘show’ and ‘erase’:
G450Qu-018(super)# show crl

5 Apr 11 22:47:23 2013 Apr 11 22:47:23 2014 429
Done!
G450Qu-018(super)# erase crl 6
• This
Index is the CRL that you are
Issuer-Common-Name about to erase:
Last-Update Next-Update Size
Do you want to continue (Y/N)? y
Done!
• G450Qu-018(super)#
Now you can use thecrl‘show’ command to review:
show

5 Apr 11 22:47:23 2013 Apr 11 22:47:23 2014 429
Done!
Appendix A
Certificate Management for CM

Duplex Servers

CM Administration
 This Appendix has been provided to guide the user through the steps of loading CA
certificates and Identity certificates onto a CM Server pair.
 Note that this pair of servers has an alias DNS name and an alias IP address. In this
example:
– Alias DNS name is “aji-srv.dr.avaya.com”
– Alias IP address is “135.9.138.51”
 The DoD customer will employ 3rd party hosted certificates. This means that the
certificates were generated on a pc/workstation that is using an OpenSSL toolkit.
Examples of using this interface will be demonstrated immediately in the following slides.
– Since some customer may require the use of the SubjectAltName field in the CM Identity
certificates, our example will include the specification of this as well.
 Finally the CM web server command interface will be illustrated with Screen pictures to
guide the user through downloading certificates onto the primary and the backup servers.
 Note that the examples are for loading the “C” repository. Many customers will load this
same CM Identity certificate into the “W” repository as well!

Using a Standard OpenSSL Toolkit to create
IdentityCertificates
 The first step is to create a new key file for the Identity Certificate Signing Request (CSR):
[root@aji-srv2 newcerts]# openssl genrsa -out dupServer.key 2048
Generating RSA private key, 2048 bit long modulus
...........................................+++
.........................................................................................+++
e is 65537 (0x10001)
 The second step is to create a CSR from this key.

– The OpenSSL configure file in /etc/pki/tls/openssl.cnf must be modified to support the inclusion
of the SubjectAltName [IP: 135.9.138.51]
– It should be noted that the Subject AltName can be of format type “IP”, “DNS”, or “URI”.
req_extensions = v3_req # The extensions to add to a certificate request

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName=IP:135.9.138.51

IdentityCertificates (continued)
 The second step (continued from last page) is to create a CSR from this key:
[root@aji-srv2 newcerts]# openssl req -new -key dupServer.key -out dupServer.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [Colorado]:
Locality Name (eg, city) [Thornton]:
Organization Name (eg, company) [Avaya]:
Organizational Unit Name (eg, section) [cmcpe]:
Common Name (eg, your name or your server's hostname) []:aji-srv
Email Address []:
Please enter the following 'extra' attributes

to be sent with your certificate request
A challenge password []:
An optional company name []:

Identity Certificates (continued)
 The third step is to have this cert file signed. For this example we have used a private root
CA in a lab environment (named dupRootCA.
[root@aji-srv2 newcerts]# openssl x509 -req -in dupServer.csr -extfile
/etc/pki/tls/openssl.cnf -extensions v3_req -CA dupRootCA.pem -CAkey dupRootCA.key -
CAcreateserial -out dupServer.pem -days 1095
Signature ok
subject=/C=US/ST=Colorado/L=Thornton/O=Avaya/OU=cmcpe/CN=aji-srv
Getting CA Private Key
 We can now view the certificate that we have made by:

[root@aji-srv2 newcerts]# openssl x509 -noout -text -in dupServer.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
f5:59:c9:90:70:10:00:8a
Issuer: C=US, ST=Colorado, L=Thornton, O=Avaya, OU=cmcpe, CN=aji-srv
Validity
Not Before: Jan 26 21:00:20 2016 GMT
Not After : Jan 25 21:00:20 2019 GMT
Subject: C=US, ST=Colorado, L=Thornton, O=Avaya, OU=cmcpe, CN=aji-srv
RSA Public Key: (2048 bit)

Modulus (2048 bit):

00:db:b1:35:cd:2c:ef:51:90:ee:f8:b5:88:01:41:
8c:bb:4d:e7:d7:08:fa:27:56:ab:45:c7:40:c8:e6:
2b:4e:d0:22:17:b5:7b:26:37:11:ee:93:d1:67:71:
ad:6a:61:28:65:d5:62:dc:28:ee:31:1a:79:4e:53:
b8:c2:78:c2:f1:a0:3d:8a:db:3b:15:e3:f7:38:b7:
93:72:10:af:e0:dd:0f:5e:45:b6:94:12:0d:b0:9a:
2a:66:d2:b2:1f:5f:44:ee:7d:78:65:65:aa:6e:c6:
6c:90:a8:41:db:e3:72:e3:b4:d7:4c:f0:7e:ba:1d:
d2:ff:e7:c7:0f:ef:48:8a:20:dd:08:c5:bb:04:c9:
d1:15:77:ab:ef:1c:c5:d7:40:dc:2d:05:43:12:a9:
42:33:fd:07:bf:97:9b:08:b5:a3:15:82:07:7b:45:
82:5d:fc:ea:dd:d7:d9:64:bc:7b:74:bd:e7:27:43:
3e:2f:6d:67:fc:df:9e:1a:84:b2:10:4e:ce:04:e9:
7f:64:bb:ef:fd:7c:6f:a5:15:40:04:dd:e8:2e:43:
ac:8c:d9:88:65:6d:5b:71:86:cc:d9:3e:fc:18:73:
6c:fe:50:22:0f:d6:a2:f7:fc:c6:0e:3e:8c:07:32:
ee:a3:57:4b:f8:90:d9:a3:9c:29:57:33:a7:63:40:
4b:09
Exponent: 65537 (0x10001)

X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Alternative Name:
IP Address:135.9.138.51
92:e6:04:96:2f:6f:66:99:8c:e4:80:9a:03:1a:b2:24:65:db:
03:8a:ca:28:ef:38:c1:4e:74:4b:b5:69:ca:be:b7:08:1a:82:
30:3e:11:7d:de:10:50:1b:10:67:b5:23:44:b3:96:c6:f5:38:
f7:85:81:7a:d6:42:75:d4:c9:b7:39:c8:fe:48:e7:58:52:11:
4a:bb:12:5c:fd:89:44:3a:89:ee:a1:3e:71:36:7c:35:04:d9:
89:2c:3d:67:dc:a6:4a:81:8e:76:98:1d:0d:b1:4b:d7:9b:08:
a7:32:1b:55:af:bc:c1:45:16:d3:0f:37:e6:78:3a:eb:b9:41:
a9:4a:81:34:68:b2:d2:e6:2b:ef:f6:03:2b:a0:59:0c:cb:a5:
d1:53:31:bc:8d:28:49:5c:6f:0c:f0:5b:d9:55:28:84:99:0d:
e7:bd:60:d3:ad:58:4c:02:fc:e8:97:5b:d0:3e:24:64:36:b7:
7c:5c:fd:7f:d8:9b:95:7a:24:56:19:fc:c7:e8:d1:36:09:0f:
9b:20:ae:18:13:33:75:62:04:7f:f4:03:21:da:f3:de:87:2c:
87:7a:e0:f7:2a:7a:3e:65:dc:d8:97:ed:a9:8c:25:b0:ed:78:
1e:ac:1e:f9:65:21:21:26:ff:35:36:a4:bc:f2:31:a3:fa:e7:
dd:73:53:39

 The fourth step is to create a PKCS12 certificate package for installation on the CM
server.
[root@aji-srv2 newcerts]# openssl pkcs12 -export -out dupServer.pfx -inkey dupServer.key -in
dupServer.pem -certfile dupServer.pem
Enter Export Password:
Verifying - Enter Export Password:
 We will now view the PKCS12 bundle (as a simple check)

[root@aji-srv2 newcerts]# openssl pkcs12 -noout -info -in dupServer.pfx
Enter Import Password:
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
 A view of our current file directory has the following files for CA Root and Identity Cert
displayed:
[root@aji-srv2 newcerts]# ls
dupRootCA.key dupRootCA.pem dupRootCA.srl dupServer.csr dupServer.key dupServer.pem
dupServer.pfx

 The fifth step is to copy the Root CA pem file and the Identity pkcs12.pfx file into the
following directory on the active CM server
– /var/home/ftp/pub
[root@aji-srv2 newcerts]# cp dupRootCA.pem /var/home/ftp/pub

[root@aji-srv2 newcerts]# cp dupServer.pfx /var/home/ftp/pub
 We must also copy the CM Identity cert file over to the standby CM server in its
/var/home/ftp/pub directory.
 Note that there is NO need to copy the root CA cert file to the Standby CM server. This is
copied by CM’s active server, as part of server synchronization, immediately after the CA
cert was installed onto the active CM server.
 Now we are at the point of loading the certs. Go to the Active CM’s SMI web page and
vector to Administration>Server Maintenance>Security>Trusted Certificates and press
“Add”.

CM Administration for Duplicated Server


repository (second line for this example). Starting in R7.1, CM does NOT have to be restarted
for this CA to take effect.

 For loading the Identity Cert for CM Server 1, select “Server/Application Certificates and press “Add”.
select “Open”.

“Add”.

 For loading the Identity Cert for CM Server 2, select “Server/Application Certificates and press “Add”.
select “Open”.

“Add”. This completes the CM DUP Server certificate installation.

Use of SubjectAltName in the Identity Certificates
in Avaya Aura ® Components
 Certificates have two fields which serve to identify a product

– Common Name
– SubjectAltName
 The policy rules for a receiver to examine certificates is governed by RFC 2818.
 In R6.3-FP4; CM, SM, and the Media Gateways do not support validation using the
SubjectAltName field.
 The 96x1-H.323 phones have a Settings File parameter, TLSSRVRVERIFYID, that is
employed to direct the phones in name field validation
– TLSSRVRVERIFYID = 0: No validation of name fields
– TLSSRVRVERIFYID = 1: Validation of name fields in accordance with RFC 2818
 Examples:
1) With TLSSRVRVERIFYID=0: When creating the CM certificate, program the CN to a host
name value which is not in our DNS system and set the SubjectAltName to blank.
Observe that the H.323 station registers and can complete calls successfully.
 Observe that the phone performed no validation on name fields of the peer (CM’s) cert.
2) With TLSSRVRVERIFYID=1: When creating the CM certificate, program the CN to the IP

address of the CM server and set the SubjectAlternateName to blank. Observe that the
H.323 station registers and can complete calls successfully.
 Observe that the phone validated Identity based only upon the CN field

Use of SubjectAltName in the Identity Certificates
in Avaya Aura ® Components (continued)
 Examples (continued).
3) With TLSSRVRVERIFYID=1: When creating the CM certificate, program the CN to
the CM host name value and set the SubjectAlternateName to blank. Observe that the
H.323 station fails to register and calls can not be completed.
 The phone fails to authenticate because it can’t determine the CN Identity. The phone
displays an authentication error message.
4) With TLSSRVRVERIFYID=1: When creating CM certificate, program the CN set to
a CM hostname value which is valid in our DNS system and the SubjectAltName field
set to the IP Address of the CM server. Observe that the H.323 station can register
and can complete calls successfully.
 The phone validates based upon the SubjectAltName field.

Appendix B
Creating SMGR Signed Identity

Certificates for CM

CM Administration
(for Avaya System Manager to serve as a CA to Sign Identity
Certs)
 As an alternative to the use of third party certificates, the customer’s Security

Administrator may choose to have the Avaya System Manager serve as a signing
authority. The advantage of this scheme is that a customer may desire that SMGR serve
as a common CA across the certificates use in several Avaya Aura ™ products.
 The following pages illustrate:
– CM creates an Identity Certificate request (including creating the unsigned certificate).
– The Security Administrator then copies this draft cert and pastes this into the SMGR Signing
request screen.
– The Administrator imports this SMGR-signed (CA & CM Identity ) cert package into the CM trust
stores.

SMGR Administration
-Creating an Identity cert for CM
 Start by logging into SMGR and selecting the “Services>Security ” option.

SMGR Administration
- Creating an Identity cert for CM (continued)
 In the Security screen, select “Certificates” to enter the cert management screen.

SMGR Administration
 Select “Authority” to enter the EJBCA Administration.

SMGR Administration
 In order to create an Identity cert for a CM switch, we first need to register CM with the
Registration Authority (RA). To do this, select “Add End Entity” under the Functions navigation
entry.

SMGR Administration
 Type a “username” and “password”. This password is used to encrypt the PKCS12 file store
which is exchanged (after being signed) and sent from SMGR down to the CM server.
 Complete the fields that will be inserted into the certificate signing request:
• E-mail address: labmanager@yourcompany.com
• CN (Common Name): aeshostname.yourcompany.com
• OU (Organization Unit): IT
• O (Organization): Your company name
• L (Locality):Your city
• ST (State or Province): Your state
• C (Country): Your country
 In the “Certificate Profile” drop-down menu, enter “ID_Client_Server”.
 In the “CA drop-down menu, enter “tmdefaultca”.
 In the “Token drop-down menu, enter “P12” file.
 Click on the ‘Add’ button.
 The top of the page of the system displays the message “End Entity<username> added
successfully”.
 An example of this is illustrated on the next slide:

SMGR Administration
 This illustrates an example of the ‘Add End Entity’ screen entry, with all field entries completed.

SMGR Administration
 Create the CM server’s Identity certificate as follows:

– Using the SMGR web console, navigate to “Security<Certificates>Authority.
– In the left hand navigation pane, click on “Public Web”.
– On the “Public Web” screen click on “Create Keystore”.

SMGR Administration
 Enter the username and password of the “End Entity” and click “OK”.

SMGR Administration
 Select the Certificate Key Length (2048 is recommended).

 Click on “Enroll”.

SMGR Administration
 Save the server certificate into a known location on the SMGR file space.
 Note: This is the signed server certificate that you have to import into the CM server.

SMGR Administration
-Download the SMGR CA Certificate that Signed the CM ID Cert
 Using the SMGR web console, navigate to the “Public Web” page and click on “Fetch CA
Certificates”.
 Click on the url for “Download PEM chain” (on the line starting with “CA certificate Chain”).

SMGR Administration
- Download the SMGR CA Certificate that signed the CM ID Cert
 Save the CA certificate to a known location. Note that this is the CA certificate (from SMGR)
that needs to be imported into the CM server.

CM Administration
-Import the SMGR CA Cert into the CM Trusted Store
 Login to the CM server’s Web SMI pages and navigate to “Administration>Server
(Maintenance)>Download Files” screen.
 Select “Files(s) to download from the machine I’m using to connect to the server” to copy files
from your PC over to the CM server. Note that you will be pointing to the SMGR CA file and the
CM Identity file.

CM Administration
-Import the SMGR CA Cert into the CM Trusted Store
 Press the “Download” button to complete the process.
 The files will be loaded onto the CM server in the /var/home/ftp/pub directory.
Trust Chain for CA that signed the ID cert
Identity cert

CM Administration
-Adding the Downloaded CA File into the CM Trusted Store
 From the administration navigation pane, select the “Trusted Certificates” screen.
 Type in the name of the CA.pem file and select “Open”.

CM Administration

CM Administration
repository (second line for this example). Starting in R7.1, CM does NOT have to be restarted
for this CA to take effect.

CM Administration
-Loading the CM Server’s Identity Certificate
 For Identity certificates, select “Server/Application Certificates and press “Add”.
select “Open”.

CM Administration
 You will see the Identity certificate listed. Then select the Communication Manager repository
and press “Add”.

CM Administration

Appendix C
Certificate Signing Request for

SMGR Signed Certs

Overview for Certificate Signing Request
for SMGR Signed Certs
 CM has a SMI page entitled, “Certificate Signing Request”.
– This enables a Security Administrator to enter a set of Identity Certificate profile
entries.
– Then a Certificate Signing Request (CSR) can be sent to a signing authority. The
CSR will contain a certificate file which must be signed by a Certificate Authority
(CA).
 The Avaya Aura ™ System Manager (SMGR) supports a EJBCA support for
the ability to serve as a “Self Signed Certificate Authority” and provide a digital
signature to validate the certificate.
– SMGR will encrypt this certificate file with a password and return it to CM.
 Upon reception of this certificate file, CM will use its private password to
decrypt the file and save it into the proper Identity Certificate repository store.
 Cautionary Note: The CSR SMI page does not support some of the more
recent extensions to the certificate structure. Notably, the
subjectAlternateName extension is not available. If a customer requires these
extensions, the alternative to use “3rd Party Hosted” certificates is advised.

CM Administration
- Generating a CM Certificate from a Cert Signing Request
 Login to the CM server’s Web SMI pages and navigate to “Administration/Server
(Maintenance)>Certificate Signing Request” screen.

CM Administration
 Enter the information on the CSR form (see the example below). Then press the “Generate
Request” button.

Some Notes for CM’s Certificate Signing
Request
 The next slide will illustrate the SMI page for “Certificate Signing Request –
Display”. This will display that actual generated CSR.
 Note that in internal memory, CM keeps a copy of the corresponding private
key and the CSR file in the /etc/opt/ecs/certs/cm/signing_requests directory.
This data will be used when the actual signed certificate is installed.
 Once a CSR file is created, it should not be removed until the signed certifcate
is received from SMGR and is installed into CM’s Trust Store and Server
Application Repository.
 The CM CSR SMI page keeps a record of generated CSR’s and these may be
view again after the CSR is actually signed.

CM Administration
 In response the “Certificate Signing Request – Display” screen will be shown. This contains all
of the certificate file.
 From this screen, the user can scroll down and select (with the mouse) the data starting with
“BEGIN CERTIFICATE REQUEST” and ending with the line “END CERTIFICATE REQUEST”.
This can be pasted directly into the SMGR’s “Certificate Request” screen.

SMGR Administration
-Certificate Enrollment from a Cert Signing Request
 On the SMGR, go to the “Security>Certificates>Authority” screen and select the Public Web
item. On the navigation pane, select the option “Create Certificate from CSR”.

SMGR Administration
 On the SMGR’s “Certificate Enrollment from CSR” form, enter the Username and Password that
was administered in the SMGR RA for this SIP End Entity.
 Then paste the CSR file that you copied fro the CM’s “Certificate Signing Request” screen.
 Select a “.PEM” file type and press “OK”.

SMGR Administration
 The SMCR will display a screen, “Certificate Created”.
 Follow the procedures for downloading both the CM Identity Certificate and the SMGR’s CA
certificate as outlined in Appendix B (slides #104 thru #113):

Browser Certificate Manager
-Verification of Certificate Installation
 The Security Administrator can perform a few basic status commands to view the installation.
 As a browser example (with Firefox), you can select Options>Advanced>View Certificates which brings up a screen entitled “Certificate
Manager”. Select the “Authorities tab and scroll down.
 You will observe an entry for “System Manager CA”.
 Similarly, you can enter CM’s SMI pages to view the Identity Repositories in order to validate that an Identity Certificate (signed by SMGR)
is loaded.

Appendix D
Certificate Signing Request for

Certificate Service Provider (CSP)
Signed Certs

Overview for Certificate Signing Request
for Certificate Service Provider (CSP)
Signed Certs
 CM has a SMI page entitled, “Certificate Signing Request”.
– This enables a Security Administrator to enter a set of Identity Certificate profile
entries.
– Then a Certificate Signing Request (CSR) can be sent to a signing authority. The
CSR will contain a certificate file which must be signed by a Certificate Authority
(CA).
 The Certificate Service Provider will provide a digital signature to validate the
certificate.
– The CSP will encrypt this certificate file with a password and return it to CM.
 Upon reception of this certificate file, CM will use its private password to
decrypt the file and save it into the proper Identity Certificate repository store.
 Cautionary Note: The CSR SMI page does not support some of the more
recent extensions to the certificate structure. Notably, the
subjectAlternateName extension is not available. If a customer requires these
extensions, the alternative to use “3rd Party Hosted” certificates is advised.

CM Administration
 Login to the CM server’s Web SMI pages and navigate to “Administration/Server (Maintenance)>Certificate
Signing Request” screen.
 Enter the information on the CSR form (see the example below). Then press the “Generate Request” button.

Some Notes for CM’s Certificate Signing
Request
 The next slide will illustrate the SMI page for “Certificate Signing Request –
Display”. This will display that actual generated CSR.
 Note that in internal memory, CM keeps a copy of the corresponding private
key and the CSR file in the /etc/opt/ecs/certs/cm/signing_requests directory.
This data will be used when the actual signed certificate is installed.
 Once a CSR file is created, it should not be removed until the signed certifcate
is received from Certificate Service Provider and is installed into CM’s Trust
Store and Server Application Repository.
 The CM CSR SMI page keeps a record of generated CSR’s and these may be
view again after the CSR is actually signed.

CM Administration
 In response the “Certificate Signing Request – Display” screen will be shown. This contains all
of the certificate file.
 From this screen, the user can scroll down and select (with the mouse) the data starting with
“BEGIN CERTIFICATE REQUEST” and ending with the line “END CERTIFICATE REQUEST”.
This can be pasted directly into the CSR request letter that is mailed to the CSP.

CM Administration
- Viewing outstanding Certificate Signing Request(s)
 If you wish to view outstanding Certificate Signing Requests, you can re-enter the SMI page for
“Certificate Signing Request”.
 Once the signed CSR generated certificate pair are imported, CM will remove that entry from
the list. A maximum of “6” signing requests may be outstanding at any one time.

Steps for Downloading Signed Certs from
CSP
 The Certificate Signing Provider should return:
– Signed Identity certificate for CM
– A corresponding CA certificate bundle containing the Certificate Authority
verification chain from the Root CA down through the lowest tier of Intermediate
CA.
• In some cases, there may be only a single certificate which is the Root CA which signed
the CSR directly (example could be SMGR serving as a Self-Signed CA).
– Store these on the craftsperson’s local computer.
 To install a CA certificate bundle containing a Root CA certificate and one or
more Intermediate CA certificates, you must first separate the certificates into
separate files because CM cannot handle multiple CA certificates in the same
file.
– It is advisable to load the CA files onto CM in the order that they are formed in this
bundle which has been sent down from the CSP.
 The last step is to go to the CM SMI page for “Miscellaneous/Download Files”,
and browse to the correct files where these are stored on the craftsperson’s
local computer.

CM Administration
-Downloading a CA and Identity Certificate into CM Server
 Go to Administration/Server > Miscellaneous > Download Files and browse to the directory on
your computer where you have stored the certificate pair. Then select “Download”
 The files will be downloaded into the /var/home/ftp/pub directory on this CM server.

CM Administration

CM Administration

CM Administration
repository (first line for this example). Starting in R7.1, CM does NOT have to be restarted for this
CA to take effect.
 Note: When updating CM’s Trust Store, please consider removing old entries that are not in use.

CM Administration
 For Identity certificates, select “Server/Application Certificates.
select “Open”.

CM Administration
 You will see the Identity certificate listed. Then select the Communication Manager repository
and press “Add”.

CM Administration
-Web Server Certificate Management Help Screen
 If you are having any questions during this ‘Add’ process, you may select the “Help” tab. The
SMI interface server will present the following task information:

TLSandCertGuidelineforR7 1 Ver 0 1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TLSandCertGuidelineforR7 1 Ver 0 1

Uploaded by

Copyright:

Available Formats

TLS & Certificate Management Guidelines for CM R7.

Development/Tier 4 Engineers: Wayne Zakowski,

Avaya – Proprietary. Use pursuant to Avaya policy. 2

Avaya – Proprietary. Use pursuant to Avaya policy. 3

Avaya – Proprietary. Use pursuant to Avaya policy. 4

 Avaya’s approach for cert management is to:

Avaya – Proprietary. Use pursuant to Avaya policy. 5

Record Protocol Exchange

Avaya – Proprietary. Use pursuant to Avaya policy. 6

End-Entity End-Entity End-Entity

CM Identity GW Identity H.323 Phone Identity

Avaya – Proprietary. Use pursuant to Avaya policy. 7

Avaya – Proprietary. Use pursuant to Avaya policy. 8

 CM has four application directories to hold possible certificates:

– W => Apache Web Services (HTTPS)

 Security Administrator may download certificates from hosted server

Avaya – Proprietary. Use pursuant to Avaya policy. 9

Peers SIP Signaling

Avaya – Proprietary. Use pursuant to Avaya policy. 10

Avaya – Proprietary. Use pursuant to Avaya policy. 11

Avaya – Proprietary. Use pursuant to Avaya policy. 12

 Gateway has two application directories to hold possible certificates:

Avaya – Proprietary. Use pursuant to Avaya policy. 13

Avaya – Proprietary. Use pursuant to Avaya policy. 14

Operation of H.323 phone for Initial Registration and TLS connection

Avaya – Proprietary. Use pursuant to Avaya policy. 16

(for non-TTS H.323 Gatekeeper Confirm H.225/RAS

Open TCP socket

Registration Register Request

Signaling Channel SETUP FastStart H.225/

Call Information H.225/

Avaya – Proprietary. Use pursuant to Avaya policy. 17

Avaya – Proprietary. Use pursuant to Avaya policy. 18

Open TCP socket TCP port 1300 Server Interchange; or

Call Information H.225/Q.931,

Avaya – Proprietary. Use pursuant to Avaya policy. 20

Avaya – Proprietary. Use pursuant to Avaya policy. 21

Avaya – Proprietary. Use pursuant to Avaya policy. 22

 The CM’s CLI command to enable and disable FIPSMode is “fips_mode”.

Avaya – Proprietary. Use pursuant to Avaya policy. 23

Avaya – Proprietary. Use pursuant to Avaya policy. 24

Avaya – Proprietary. Use pursuant to Avaya policy. 25

 Type in the name of the CA.pem file and select “open”.

Avaya – Proprietary. Use pursuant to Avaya policy. 26

Avaya – Proprietary. Use pursuant to Avaya policy. 27

Avaya – Proprietary. Use pursuant to Avaya policy. 28

Avaya – Proprietary. Use pursuant to Avaya policy. 29

Avaya – Proprietary. Use pursuant to Avaya policy. 30

Avaya – Proprietary. Use pursuant to Avaya policy. 31

Avaya – Proprietary. Use pursuant to Avaya policy. 32

Avaya – Proprietary. Use pursuant to Avaya policy. 34

display capacity Page 11 of 13

CONCURRENT REGISTRATION COUNTS

IP PORT USAGE COUNTS

IP Station Ports Used By

– Large CM Platform => 18000 H.323 phones

Avaya – Proprietary. Use pursuant to Avaya policy. 36

display ip-network-region 1 Page 3 of 20

INTER-GATEWAY ALTERNATE ROUTING / DIAL PLAN TRANSPARENCY

BACKUP SERVERS(IN PRIORITY ORDER) H.323 SECURITY PROFILES

TCP SIGNALING LINK ESTABLISHMENT FOR AVAYA H.323 ENDPOINTS

Avaya – Proprietary. Use pursuant to Avaya policy. 37