Device Certificate Authentication Considerations For Scep - Avaya 1230 Administration

3. The IP Deskphone prompts the user to enter a password to be included in the certificate
request the IP Deskphone is about to generate. A password may or may not be required
depending on the configuration of the SCEP/CA server.
4. The IP Deskphone generates a device certificate request which is forwarded to the certificate
authority using the SCEP command PKCSReq.
5. After the device certificate request is approved, the CA signs the device certificate request
with the CA private key and returns the completed certificate to the IP Deskphone.
6. The IP Deskphone stores the device certificate and the IP Deskphone private key into the
IP Deskphone memory with the matching private key.
7. The IP Deskphone can now verify the identity of the device certificate when requested by a
server.
During the enrollment process, and before the IP Deskphone sends the device certificate request to
the CA server, the IP Deskphone prompts the administrator to enter a challenge password. The use
of a password is optional depending on the configuration of the SCEP server. If the SCEP server is
configured to not require a password, the administrator does not enter a value and presses the OK
Context-sensitive soft key.
The name included in the device certificate request is constructed using the hostname and domain
name shown in the Network Configuration screen immediately under the CA server. If there is no
hostname entered, a hostname is created using the IP Deskphone MAC address according to the
form NTIPP012345, where NTIPP is an acronym for IP Deskphone and 012345 are the last six hex
digits of the MAC address. By default, the certificate request includes a Subject Common Name in
the form of hostname@domainname. The SCEP configuration fields in each DCP provide more
flexibility in the form and location of this name.

Device Certificate Authentication Considerations for SCEP

An important aspect of the device certificate request is the format and location of the name that is
requested for the device certificate. The server presented with a device certificate by the IP
Deskphone always confirms the authenticity of the certificate by verifying that the issuer of the
device certificate is trusted by the server and that the signature on the device certificate is authentic
by performing certificate chain validation. A server also performs verification based on the name
contained in the device certificate. Therefore, the name contained in the device certificate must be
appropriate to the type of authentication that the server uses. The Subject Common Name (CN), the
full Subject Distinguised Name (DN), or the Subject Alternate Name (SAN) is used to determine if
the entity has the necessary permissions.
For example, if Microsoft IAS is used as the RADIUS server for EAP-TLS authentication, the CN in
the certificate must be the User Principle Name (UPN) of a valid user registered in the Active
Directory configured for remote access. Other RADIUS or TLS servers can impose different
conditions on the certificate name.
March 2015
Device Certificate Authentication Considerations for SCEP
SIP Software for Avaya 1200 Series IP Deskphones-Administration
Comments? infodev@avaya.com
253