RMAUG May 2016 Sandy Abramson Avaya Confidential amp Proprietary Use pursuant to your agreement or Avaya policy Why do we need to talk about Certificates Avaya products are using Digital Certificates for some time ID: 759496
Download Presentation The PPT/PDF document "Avaya Aura Security Certificates Demys..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Avaya Aura Security Certificates Demystified
RMAUGMay 2016Sandy Abramson
Avaya – Confidential & Proprietary Use pursuant to your agreement or Avaya policy
Slide2Why do we need to talk about Certificates ?
Avaya products are using Digital Certificates for some time.
Non-unique Avaya
SIP Product CA
Certificates were used previousely acrosss products to provide out-of-box
lab/demo/default
support for TLS.
The Avaya Default certificate is a SHA1/1024 identity certificate no longer meets
current NIST standards.
New
greenfield installations do not come with default CA certs
New SM servers no longer use the Avaya “SIP Product CA” issued Default Certificates.
The new generation of Avaya Communicator Clients will no longer trust demo Certificates and require servers to have certificates issued by a trusted CA in order for the client to establish a secure connection
.
A
new CA certificate must be created via SMGR
EJBCA (recommended
), Enterprise (Private) CA, or a third party trusted root authority
.
The Default certificate that came with each product should be upgraded
.
All products
deployed in an enterprise must
be on the same secure hash algorithm and bit size key across a solution i.e., – SHA1 2048 or SHA2 2048
Slide3Why do we need to talk about Certificates Continued?
Default Certificates are not considered secure for a production environment, and therefore new SM servers no longer use the Avaya “SIP Product CA” issued Default Certificates.The new generation of Avaya Communicator Clients will no longer trust Default Certificates and require servers to have certificates issued by a trusted certificate authority in order for the client to establish a secure connection.
Product Support Notice:
PSN004253u,
PSN004246u, PSN004251u
Product Support
Notice
:
PSN004253u
,
PSN004246u
, PSN004251u
Slide4Industry is moving SHA-1 encryption to the vastly more secure SHA-2
The
longer you wait, the less time you'll have to do it without panicking.
Over the coming years, particularly this one and next, many digital-certificate-consuming devices and applications will begin to display warnings/errors or operationally fail if a digital certificate containing the SHA-1 (or earlier) hash is presented. Why the change? Because the SHA-1 hash has been shown to suffer cryptographic weaknesses to the point where many experts think its days of useful protection are numbered.
Of course, SHA-1 is the most common hash today, and many applications and devices don’t yet accept or understand SHA-2-related hashes or certificates. There's the rub.
Intro to SHA
SHA-1 was designed by the NSA and published as a federal standard in 1995. Hashes are used for digitally signing content for integrity validation and are a part of any digital certificate. Without cryptographically sound hashing algorithms, digital authentication and integrity would be very hard to do, if not impossible.
In 2002, SHA-2 became the new recommended hashing standard. SHA-2 is often called the SHA-2 family of hashes because it contains many different-size hashes, including 224-, 256-, 384-, and 512-bit digests. When someone says they are using the SHA-2 hash, you don’t know which bit length they are using, but the most popular one is 256 bits (by a large margin). Although SHA-2 is constantly attacked and minor weaknesses are noted, in crypto-speak, it's considered "strong." Without question, It's way better than SHA-1, which experts believe will be fallible in the near term
.
Slide5SHA-1 deprecation handling
No
surprise that many software vendors, especially those with browsers (which consume most of the digital certificates we use today), are actively moving to SHA-2. Expect most Internet browsers to display warning messages or errors soon. Here's a decent summary of the
major browser vendors' position statements
.
Each vendor will handle matters differently, but devices will move slower than software products, simply because software is easier to upgrade. Of course, in many cases, the software with which you access the hardware device will dictate the SHA migration. For example, the LogRhythm event log appliance requires Google’s Chrome browser for access and management -- and Chrome is moving to SHA-2.
Starting this year,
Google’s Chrome browser
will simply show a warning indicator for SHA-1 certificates with validity dates past Jan. 1, 2016. For certificates with validity dates past Jan. 1, 2017, there will be a warning, plus the protected content will be treated as mixed content, which will require additional user interaction.
Microsoft has announced an even
more aggressive stance
:
Slide6SHA-1 deprecation handling
There
will be separate timelines for discontinuing SHA1-based SSL and code signing end-entity certificates …
CAs
must stop issuing new SHA1 SSL and Code Signing end-entity certificates by 1 January 2016
…
For SSL certificates, Windows will stop accepting SHA1 end-entity certificates by 1 January 2017. This means any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017 …
For
code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps after 1 January 2016.
S
HA1
code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.
Check with vendor of your browser of choice for more details. It’s expected that most public CAs (Certification Authorities) will no longer issue SHA-1-based certificates with useful lives beyond Jan. 1, 2017. Everything after will be SHA-2. If you currently have a public-facing website with an SHA-1 Web certificate, you’ll most certainly want to upgrade to SHA-2 before that date.
Unfortunately, the move from SHA-1 to SHA-2 is a one-way operation in most server scenarios. For example, once you move your Web server’s certificate from SHA-1 to SHA-2, clients that don’t understand SHA-2 certificates may see warnings or errors -- or fail. SHA-2 migration will be a risky jump for unsupported applications and devices
.
Slide7Public Key Infrastructure Overview
1
Slide8Introduction to Access Control Policy
To be able to access data and applications from within a company, a user first needs to be authenticated, and then needs to be authorized to perform the operation.
Authentication Procedures
perform the former task, and
Access Control Decision
functions perform the later task.
Slide9Password Authentication
When a company has several applications hosted by different systems and servers, there
are
several ways of identity
authentication.
Multiple
passwords, one
for each system/application
Same password, replicated in each system
Single
sign-on software
Directory Server
Slide10Symmetric and Asymmetric Encryption
The objective of encryption is to transform a message
to
a
cipher text
, ensuring
confidentiality
In the
symmetric encryption
schemes
the
same key (called the secret key) is used to both encrypt and decrypt the text
.
Ex :- DES algorithm.
Asymmetric
cryptosystems
use
one key (the public key) to encrypt a message and a different key (the private key) to decrypt
it.
Ex:- RSA and ECDSA algorithms.
Slide11Contd…
Comparison between symmetric and asymmetric encryption
Slide12Hashing
Hashing is the method used to obtain a "digital fingerprint" (hash) for a given message. The hash code has a fixed-length (normally 128 or 160 bits) and it's designed to be uniqueSome examples are MD2, MD4, MD5 (128 bits) and SHA1 (Secure Hash Algorithm,160 bits ) SHA2 256 bits
Slide13Digital Signature
To obtain a secure digital signature
,
At
first the message is
hashed creating
a digital fingerprint which is encrypted using the receiver's public key
Creating
a digital signature. The clear message is combined with the digital signature
The
result (an authenticated message) is
sent
After
the reception, the message is separated from the digital signature
which
is decrypted using the receiver's private key
The
message is hashed into a "temporary" digital fingerprint
which
is used to validate the received fingerprint
If
the message has not been modified during the transfer process, it's authenticated.
Slide14Mechanism of Digital Signature
Slide15Public Key Infrastructure
Three different formats of messages can be used in public-key cryptosystems: Encrypted
message,
Signed
message,
Signed and encrypted
message.
A
n
infrastructure must be set-up to allow them to be undoubtedly
trusted
,
as
they are accessible via unsecured networks (Internet
)
PKI entities:
-CA ( certification authority )
-RA ( registration authority )
-Subscriber
-Relying Party
-Repository
Slide16PKI basic entities and operations
Slide17Certification
Certification is the fundamental function of all PKIs. The certificates provide a secure way of publishing public keys, so that their validity can be trusted.A certificate contains (at least) the basic information needed to provide a third party entity with the subject's public key: • Subject Identification information • Subject public Key • CA Identification Information • Validity (e.g. time)
Slide18Certification contd...
Cross certification :- Not all the entities will trust the same CA to hold their certificates. Cross certification is used to create the certificate between two CAs. If both CAs trust each other, a cross certificate pair is established. In other cases, only one certificate would be created, and not a pair.
Slide19Certification contd...
Certification path :- In a universe composed of several different CAs an arbitrary number of CAs must validate each other, until a certificate is obtained. This process is called certification path validation.
Slide20Validation
This is the process that ensures that the certificate information is still valid, as it can change over time.
Either
the user can ask the CA directly about the validity - every time it's used - or the CA may include a validity period in the certificate. This second alternative is also known as
offline
validation.
Slide21Revocation
T
his
is the process of informing the users when the information in a certificate is not
valid.
This is especially interesting in the absence of online validation approaches, and the most common revocation methods consist in publishing Certification Revocation Lists (CRL
).
A CRL is a "black" list of revoked certificates that is signed and periodically issued by a
CA.
Slide22Authentication
In order for the subject to gain access to its private key, it has to
possess
a smart card or an encrypted key
file
and know something (PIN or
password)
or be something (e.g. a particular fingerprint
).
Slide23Keys
Key pair models
:-
To increase the security level, different
key
pairs might exist for different functions, which may be divided into the following
categories:
•
Non-
repudiatable
message signing (e.g. e-mail
).
• Encryption/Decryption functions.
• Authentication only (e.g. LOG ON functions
).
Slide24Key Management
These are the main steps performed in a PKI structure to handle the key pairs:
•
Key Generation
•
Storage
of Private
Keys
•
Revocation
of Public
Keys
•
Publication
of certificates and
CRL
•
Key Update
•
Backup
/
Recovery
•
Escrow
/ Recovery
Slide25Migration plan
The
hardest part of an SHA-2 migration project is determining which devices and applications work with SHA-2
. If the consuming devices don’t understand SHA-2, expect failure or an error message -- which probably won't be as enlightening as “SHA-2 unrecognized.” Instead, brace yourself for: “Certificate not recognized,” “Connection not sure,” “Connection can’t be established,” “Bad certificate,” or “Untrusted certificate.”
Think of your mission to determine what will or won't work as a kind of mini-Y2K project. Start by trying to inventory every unique device, OS, and application that will need to understand SHA-2. Then put together a team of people to test whether SHA-2 works. You can tentatively rely on vendor attestations, but until you test using a SHA-2 certificate, you won’t know for sure.
Upgrading your applications and devices will not be trivial and probably take longer than you think. Even now, I see a ton of devices and applications running older versions of OpenSSL, which should have been patched following
Heartbleed
, but were not. Remember, too, that upgrading requires formal user testing and acceptance.
If you have an internal PKI (public key infrastructure), you’ll need to prepare it for SHA-2 as well. Sometimes that means upgrading your CAs, getting new CA certs, or installing entirely new PKIs. I recommend the last for a lot of reasons, mostly because a new PKI gives you a chance to start again, free of past mistakes.
Migrating from SHA-1 to SHA-2 isn’t hard technically, but it’s a massive logistical change with tons of repercussions and requires lots of testing. It's a lot easier to do over six months or two years than in a rushed panic at the end of 2016.
I don’t think most vendors know the ultimate kill date for SHA-1, but I would guess it will arrive as more and more consumers move to SHA-2. I’ve already seen lots of customers doing this, so avoid being caught up short.
Slide26Session Manager Default Certificates changes with FP4
To enhance security, we have changed the default certificates used on new SM installs
. Previous SM releases defaulted to test/demo certificates to facilitate ease of evaluation with other Aura elements and endpoints in a customer test bed. These legacy certificates were issued by the Avaya SIP Product CA.
NOTE: Avaya
has long advised customers against use of
these legacy
test/demo certificates in production
environments. We are now changing install defaults to further discourage their use in production.
On new SM installs, SM will default to NIST SP 800-131A compliant identity
certificates issued by
SMGR-CA.
The default SIP & PPM trust domains will no longer include the legacy Avaya SIP Product Certificate Authority.
On SM upgrades the SM will still inherit its previous ID certificates and SM/PPM trust stores
.
This decouples SM release upgrades from upgrades of the SM network to NIST certificates.
Slide27Session Manager Default Certificates changes with FP4 Continued
To support setups where new SMs (i.e., new installs) are added to existing networks that use previous ID certificates, we provide existing customers a method to augment SMs in their lab test beds.
FP4 SM servers can use new “initTM –d” option to install legacy test/demo certificates and the Avaya SIP Product CA trust domain. However, we strongly encourage upgrading to NIST SP 800-131A compliant certificates.
Support for third party identity certificates has not changed.
The ability to use a third party intermediate CA on SMGR has not changed although it will issue NIST certificates with SMGR FP4.
U
se Case
:
Legacy
test/demo/default Identity certificates are insecure and should never be used in production
.
Customers
can still add/replace an SM server in their test bed and use the older deprecated test/demo certificates. However the method for accessing these certificates will present an
advisory warning message
.
New customer networks will be NIST SP 800-131A compliant by default using the SMGR’s certificate authority..
Existing customers have SM and SMGR support to migrate to SMGR-CA issued NIST SP 800-131A certificates
Slide28What Services are affected ? Communicator Example
Session Manager
SIP and HTTPS (PPM)
connections are most
important because these certificates communicate with outside entities such as Communication Manager and SIP endpoints.
Slide29Example affected network elements + connections
Certificate
based
links
Example drawing
Slide30Example links
Slide31Public Key
Infrastructure (PKI) & Certificates
Certificates
bind an identity to a public
key.
The
Certificate Authority (CA) is a trusted third party,
responsible
for verifying the identity of a user and issuing a tamper resistant
digital
certificate for
applicants.
The
digital certificate is digitally signed data stating that the public-key included in the certificate belongs to the user identified by the
certificate.
The certificate signature is created by the issuing CA and can only be validated with the issuing CA
certificate.
The signature is a hash of the certificate content which has been encrypted using the issuer’s private
key.
The issuer’s public key must be used to decrypt the signature to extract the
hash.
Slide32Trusted Certificate versus Identity Certificate
Identity Certificate and Trusted Certificate are two terms to distinguish the role of a certificate.
Identity
Certificate is a certificate used to identify an application, an interface, or a device. An identity certificate is presented to the far end as a TLS connection is being established in order to identify the sender of this certificate.
Trusted certificate is used by the local system to verify the authenticity of an identity certificate received from the far end on a TLS setup.
SMGR root CA
Signed by:
SMGR root CA
Root Certificate
XXXXXXX
Signed by:
X
Identity Certificate
Slide33Typical Use Cases for Certificates
Signing of software packages to prove the identity of the software publisher and protect against tampering.
Establish a secure, authenticated TLS/HTTPS connection between two entities (client and server
).
EAP-TLS
based
authentication for 802.1x.
Slide34Secure Communication via TLS
All communications between the client and the servers in the Avaya Aura environment can be secured using Transport Layer Security (TLS) protocol.In TLS, servers are configured with an identity certificate issued by a certificate authority.When clients connect to servers, the server presents its identity certificate for the client to validate.The client checks whether the server identity certificate was issued by a certificate authority that the client trusts. If the validation succeeds, a secure connection is established.
Server Authentication
Mutual Authentication
Slide35Certificate Based Key Exchange
Slide36Migration Workflow from Default Certificates
Gather customer requirements.Gather network and architecture documentation. Selection of Certificate Authority. Discuss pros and cons with the customer.Survey of affected network elements and their interconnections.Identify elements of the network that need to be upgraded to support new certificatesDevelop the migration planning documentation._abcde_efghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvEnsure that the certificate authority (CA) issuing identity certificates is trusted throughout the network.Generate Certificate Signing Requests (CSR) for each server´s certificate.Get the CSR´s signed by the CA.On each server, install the new server identity certificate.
Audit Phase
Deployment Phase
Slide37Selection of a Certificate Authority
SMGR
as Root CA
SMGR as
SUB CA
EnterprisePKI
3´PartyPublic PKI
Slide38CA Hierarchy
Root CA: The topmost element in the PKI hierarchy. It is often provided by a 3
rd
party vender e.g., Verisign.
Root CA (e.g., Verisign)
Intermediate CA (Optional): Used for better manageability. Placed to avoid direct interaction with the Root CA.
Intermediate CA -1 (e.g., Verisign Class x)
Intermediate CA -n (e.g., Verisign Class n)
Enterprise CA -1 (e.g., EJBCA)
Customer deployment.
Enterprise CA -n (e.g.,
EJBCA) Customer deployment
.
Enterprise CA -x (e.g.,
EJBCA) Customer deployment.
Enterprise CA aka SubCA: CA used by customers for their internal deployments. EJBCA will appear at this level.
Slide39Types of Certificate Authorities (1)
Public CA
A well-known and trusted Public CA issues the
certificates.
Pros:
Save time and resources, Computing devices already trust well known CA´s. No need to manage Trust stores.
Cons:
Requires manual PKI trust chain distribution to Aura managed elements.
Manually export of Certificate Signing Request
(CRS) and
import of the signed Identity Certificate (Optional PKSC12).
No automated re-issue of Certificates that are near expiration.
Expensive and inflexible if managed elements change in a way that’s affects Certificate content.
Complex to issue device identity certificates to Deskphones
Commercial CA´s
(starting in November 2016) will
no longer provide certificates with IP addresses for private
networks.
Slide40Types of Certificate Authorities (2)
Enterprise (Private) CA
The
Enterprise creates and operates its own CA to issue the
C
ertificates
.
Pros:
Provides enterprise branded and enterprise asserted trus
t
.
PKI trust chain might be already distributed to PC´s and Smart Devices.
Cons:
Requires manual PKI trust chain distribution to Aura managed elements.
Manually export of Certificate Signing Request (CSR) and import of the
s
igned Identity Certificate (Optional PKSC12).
No automated re-issue of Certificates that are near expiration.
Slide41Deploying Third-Party CA Identity Certificates
Leverage the OpenSSL Utility to generate a Certificate Signing Request and Private Key. Edit the OpenSSL Default Configuration File to include Certificate extension attributes not available via the OpenSSL interactive prompt.The following command generates the keys & a corresponding CSR.
Get the CSR signed by the
CA.Package the signed Identity Certificate and private key into a PKCS#12 archive format.Install the third-party trusted Root certificate.Import the PKCS #12 file and install the third-party signed identity certificate (key import password required).
Slide42Types of Certificate Authorities (3)
SMGR Self Signed CA
Efficient and cost effective for phones, but requires Certificate installation in trusted store of computing device.
Pros:
Works “out of the Box”.
Independent PKI Root for VOIP solution.
High
efficient
Trust Management
of
Avaya Aura elements.
Automatically
Re-issues and deploys NIST compliant Identity Certificates when they are near expiration for all Avaya Aura elements.
Consolidate
VOIP management functions with VOIP PKI function.
Cons:
Yet
another
PKI (
for
telecom
)
to
manage.
Certificates
lack Enterprise
branding
.
Trusted Root Certificate not distributed
to
computing device.
Slide43System Manager as a Certificate Authority (CA)
System Manager is by default a Root
CA (self-signed root
certificate)
or
can be setup as a Sub-CA (from a Third Party
Certificate Authority).
U
ses
a third-party open source application, Enterprise Java Beans Certificate
Authority
(EJBCA) to issue identity and trusted certificates to applications through Simple Certificate
Enrollment
Protocol (SCEP
).
System
Manager Trust Management provisions and manages certificates of various applications, such as servers and devices, enabling the applications to have secure inter-element communication
System
Manager generates
Certificates
using SHA2 as the signing algorithm and 2048 as
the
default
key
size
.
Slide44Types of Certificate Authorities (4)
SMGR using Enterprise PKI Intermediate CA
Leverages the installation of the Enterprise CA Certificate in the computing devices trust stores and still gain the efficiency of SMGR Cert management.
Pros:
Provides enterprise branded and enterprise asserted trust.
PKI trust chain already distributed to PC´s and Smart Devices.
High efficient Trust Management of Avaya Aura elements.
Automatically Re-issues and deploys NIST compliant Identity Certificates when they are near expiration for all Avaya Aura elements.
Consolidate VOIP management functions with VOIP PKI function (Independency from Enterprise CA).
Cons:
Requires manual PKI trust chain distribution to Aura managed elements.
Enterprise Security Policy to allow Sub-CA on System Manager.
.
Slide45Types of Certificate Authorities (5)
SMGR
using 3´Party (Public) Intermediate CA
T
ypically
a third party CA such as Verisign. This configuration adds the
SMGR CA
to the existing PKI hierarchy of the third party CA. The third party CA in such scenarios acts as a Root CA.
Pros:
Save time and resources, Computing devices already trust well known
Certificate Authorities. No need to manage trust stores.
Automatically Re-issues and deploys NIST compliant Identity Certificates when they are near expiration for all Avaya Aura elements
.
Consolidate
VOIP management functions with VOIP PKI function. (
Independent from
Enterprise CA
).
Cons
:
Expensive.
Enterprise Security Policy to allow Sub-CA on System Manager.
Requires manual PKI trust chain distribution to Aura managed elements.
Slide46System Manager certificate authority as a SUB-CA. Change the default Certificate Authority (CA) that the system generated during the System Manager installation to an externally signed Sub CA.Adds SMGR CA to an existing CA hierarchy in the customer environment.Detailed documentation “Administering Avaya Aura® System Manager”
Add a new CA via
System Manager Web ConsoleMake Certificate Request Sign Certificate from 3´Party CA (Signed request with X509 Extension CA:True)Receive Certificate Response and activate CA as default CASystem Manager must have all its identity certificates updated so that they are signed by the new CA, and the new CA must be in the trust stores.Run trust initializer ScriptConfirming identity certificate updates on System Manager
System Manager as an Intermediate CA (SUB-CA)
Considerations for existing deployments: The third party Root CA must be first added to the trust store of Applications/Devices.Element Re-registering with SMGR or force elements to request new certificates.
Slide47System Manager supports two modes of trust management
Managed Elements
Unmanaged Elements
Client initiated to request a unique
identity certificate
during
installation/ initialization of
the Application. SMGR has no knowledge of the current certificates present and cannot manage the certificates.
System Manager Trust Management
Performs installation/initialization in the same manner as the unmanaged mode. The application registers then as an element in System Manager andtheir certificates can now be managed from the System Manager console.
Presence Services, AAC
Session Manager, EDP
Slide4848
PKI
Intermediate CA
Subject CA
End-Entity
CA for End-Entity
Trust Ancho
r
Relying Party
Root CA
CA Hierarchy and CA Chain Management
In
order for an SSL certificate to be trusted, that certificate must have been issued by a CA that is included in the trusted store of the device that is connecting
.
Slide49Certificate Generation Capabilities in SMGR
Generating a PKCS#12 file including a signed certificate and private key directly from the SMGR UI.For Products with PKCS#12 keystore import functionality.
Creating a signed certificate directly from the SMGR UI using a CSR.For Products generating the keys on their end and having the Certificate signed by the SMGR CA.
Creating an end entity with Certificate Parameters
Generate a PKCS12 format keystore with the Identity certificate containing the values given in the end entity.
Sign the given CSR and generate a PEM formatted certificate containing the values given in the end entity.
1
2
2
1
Slide50SMGR Root CA certificate
Root CA certificate can be downloaded from SMGR UI.
50
Slide51Session Manager Certificate Management
Session
Manager and Branch Session Manager are identical in terms of certificate management. SM Certificate operation can be performed as a managed element through SMGR. 5 SM Software components (e.g.. SIP Link, HTTP_PPM) can use different Identity and Trusted Certificates.Each SM interface can support ONE Identity Certificate only.Certificates can be replaced with a SMGR internal signed CA Certificate or an imported third party PKCS#12 file.
Slide52Session Manager TLS Layer Validation
SM applies the following validations for SIP TLS connections to other SIP Server Entities.Mutual TLS authentication: During a TLS handshake, mutual TLS authentication is performed.Additional validation of the SIP entity identity certificate: Further validation could be performed on the SIP entity Identity Certificate as per the Credential Name or the far-end IP address.
If
the credential name string is empty, the connection is accepted.
If the credential name is configured, the credential name and the IP address of the SIP entity is searched in the following places in the identity certificate provided by the SIP entity.
CN value from the subject subjectAltName.dNSName subjectAltName.uniformResourceIdentifier
XX1.example.com
Signed by:
SMGR root CA
Slide53Required Skills Based on Field Experience by ASAs
Slide54Recommendations
Installing certificates can be complicated.
Plan for certificate migration upfront and do not wait until after install
.
Both the customer (or BP) and Avaya need to take responsibility upfront for identifying a certificate strategy.
A lot of planning must be done to ensure that certificates are correctly installed.
It is highly recommended to have an ASA involved before installation.
APS has certificate expertise
Slide55Slide56SMGR Root CA certificate
Root CA certificate can be downloaded from SMGR UI.
56
Slide57Session Manager Certificate Management
Session
Manager and Branch Session Manager are identical in terms of certificate management. SM Certificate operation can be performed as a managed element through SMGR. 5 SM Software components (e.g.. SIP Link, HTTP_PPM) can use different Identity and Trusted Certificates.Each SM interface can support ONE Identity Certificate only.Certificates can be replaced with a SMGR internal signed CA Certificate or an imported third party PKCS#12 file.
Slide58Session Manager TLS Layer Validation
SM applies the following validations for SIP TLS connections to other SIP Server Entities.Mutual TLS authentication: During a TLS handshake, mutual TLS authentication is performed.Additional validation of the SIP entity identity certificate: Further validation could be performed on the SIP entity Identity Certificate as per the Credential Name or the far-end IP address.
If
the credential name string is empty, the connection is accepted.
If the credential name is configured, the credential name and the IP address of the SIP entity is searched in the following places in the identity certificate provided by the SIP entity.
CN value from the subject subjectAltName.dNSName subjectAltName.uniformResourceIdentifier
XX1.example.com
Signed by:
SMGR root CA
Slide59How to Renew expired SMGR/SM certificates
SMGR Certificate expired and admin not able to login to the web interface.
System Manager Certificate were made valid for 2 years from the installation date. If you have upgraded your System Manager to a new major release since then the certificates will have been extended by 2 years at that time.
SMGR Cert Renewal Utility
Product Support Notice: PSN003661u
SM Cert Renewal Process
Product Support Notice: PSN003617u
Slide60Communication Manager Certificate Management
The Survivable Core and Survivable Remote servers Certificate administration is separately to the Main Server. Any certificate change on the Main Server (Duplex CM pair) will be automatically synchronized to the standby server.
There are
2 methods for CM to receive an Identity certificate. Generate CSR file and submit the CSR file to the CA. Upload and add the signed Certificate (PEM Format) to selected CM services.Upload PKCS12 format file and add selected CM Services.
Each CM service can have up to 8 trusted
certificates.
Download Trusted Certificates to CM
Add Trusted Certificate to selected CM Services
CM certificate scan be managed through the CM System Management Interface web pages
CM uses up to five unique Identity Certificates for different Services/interfaces e.g. Session Manager, LDAP server. Each service/interface can only have ONE identity certificate.A single identity certificate and trusted certificate might be used for multiple CM services.
Slide61Avaya Aura® Session Border Controller Certificates
Nomenclature
Trusted Certificates are
referred to as
CA
Certificates
Identity Certificates are referred
to as
Certificates
ASBCE certificates are
managed through the SBC web
Certificates
administration page.
install
, view the information for a certificate, or delete a certificate from this page.
CA Certificates
and
Certificates
are displayed
on this page.
Can
install multiple Trusted Certificates on the SBC and on remote applications required to establish TLS connections.
The
Avaya root CA certificate is installed by default.
TLS
connections can be established with other Avaya Aura® Unified Communications products or endpoints using the default certificates.
If
a customer requires the SBC to join an Enterprise PKI system, or if the SBC needs to communicate with third-party products securely, you must install the third-party Trusted Certificate on the SBC.
Supports
multiple Identity Certificates.
All
applications on the SBC that require secure connections (TLS) with peer entities can be configured to use
one
of the Identity Certificates for remote authentication.
By
default, the SBC uses the Avaya CA self-signed Identity Certificate that establishes TLS connections with other Avaya Aura® UC products or endpoints.
If
the customer requires the SBC to join the Enterprise PKI system, or if the SBC needs to connect to third-party products securely, you must install the third party Identity Certificate on the SBC.
Slide62ASBCE Certificates Continued
Slide63Which Certificates are required for Endpoints ?
XXXXXXX
Signed by:
X
Identity Certificate
Avaya
Aura SM/PS
File Service
(Utility Server)
Data Infrastructure
802.1X EAP-TLS
HTTPS
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
HTTPS-PPM/TLS-SIP
Avaya
Aura SM
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
XXXXXXX
Signed by:
X
Identity Certificate
Avaya
Aura SM
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
XXXXXXX
Signed by:
X
Identity Certificate
SBC
SIP
H.323
Utility
Services
does not support Third-party certificates
9641 6.3 Software upgrades
Trust Store with any Sub-CA
certificates along with the root
certificate, to validate the
certificate chain right up to the root.
Very Secure CA
Signed by:
Very Secure CA
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
Very Secure CA
Signed by:
Very Secure CA
HTTPS-PPM/TLS-SIP
HTTPS-PPM/TLS-SIP
Exchange
Calendar
TLS
TLS-XMPP
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
Slide64Which Certificates are required for Endpoints ?
XXXXXXX
Signed by:
X
Identity Certificate
VPN Gateway
VPN Phone
H.323
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
XXXXXXX
Signed by:
X
Identity Certificate
SSO for local Devices
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
TLS
IPSec
Optional -
request and authenticate an identity certificate from the
PC.
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
Identity Certificate
Communication Manager
H323 over TLS
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
TLS
XXXXXXX
Signed by:
X
Identity Certificate
Very Secure CA
Signed by:
Very Secure CA
Root Certificate
TLS
H323 over TLS
Communication Manager
Mutual authentication flag can be configured per station.
Slide65Trust Store
File Service
(Utility Server)
HTTP/
HTTPs
Trusted
Certificates
(
Deskphones
)
Six (6) Root
Certificates (PEM Format) can be loaded
via
the Trustcerts
parameter into
the trusted certificate
repository.
If
the server presents an identity certificate that is issued by an intermediate CA, then
any
intermediate CA certificates along with the root
certificate must be available in the trusted Certificate Repository
The Avaya
Product Root CA and the Avaya SIP Root CA
are default
root
certificates.
If TRUSTCERTS is defined, any default trust relationship is removed.The default root certificates are included in the zip Software distribution package.
XXXXXXX
Identity
Certificate
If no certificate files are present in the trusted certificate repository (TRUSTCERTS parameter empty), any valid Identity certificate is accepted to establish a TLS connection.
Allows to initially download certificate files through HTTPS.
Slide66Troubleshooting for certificate download in 96x1 Set TRUSTCERTS
How to remove the loaded certificate from 96x1 phone.Reboot or reset of phone never remove certificate from phone TRUSTCERTSOnly way to remove the certificate from phone TRUSTCERTS is by clearing the phone using craft procedure.No UI indication for administrator to confirm the certificate is properly downloaded in phone TRUSTCERTS.Only way is to see with a ethereal trace.
Failure case for download to TRUSTCERTS
Success scenario for 96x1 phone download certificate
Slide67SYS LOG Analysis for TRUSTCERTS
For certificate related logs, below are Log categories that need to be enableSECURITY This is for certificate related issueHTTP Down load of file from HTTP serverENCRYPT Encrypted related issueCALENDER Issue if cleaner integration failSYS LOG 148.147.195.67 SECURITY: +06:30 2014 264 1 .TEL | 0 ProcessCertificates: START\n - > This message show while phone start process to down load the certificate to TRUSTCERTSSECURITY: +06:30 2014 271 1 .TEL | 0 ProcessCertificates: Add CMT_STATE_TRUSTED_CERT\n - >Phone start to add certificate to its TRUSTCERTS directory.SECURITY: +06:30 2014 281 1 .TEL | 0 PopulateEnrollList: SCEP URL not specified, bypassing enrollment\n -- >Administrator has not set ##SET MYCERTURL http://148.147.171.218/certsrv/mscep/mscep.dll in phoneSECURITY: +06:30 2014 281 1 .TEL | 0 PopulateEnrollList: SCEP URL not specified, bypassing enrollment\n -- >Phone by pass SCEP URL SECURITY: +06:30 2014 285 1 .TEL | 0 ProcessCertificates - Unblock CMT_STATE_WAIT m_bMyCertWait=0.\n -- > Pone will not start wait process in order to download the certificate vi SCEPSECURITY: +06:30 2014 498 1 .TEL | 0 Process trusted certificate done\n Phone done process certificate.SECURITY: +06:30 2014 509 1 .TEL | 0 CSecurityUtils::GetTrustedCertChain - Adding 6 certs to SSL_CTX cert store\n Phone store certificate onto TRUSTCERTS directory.As phone has 6 certificate phone will set all those in trusted directory SET TRUSTCERTS "AvayaITRoot2039.pem,smgr_ca.txt,av_sipca_pem_2027.txt,VerisignIntermediateCA.txt,VerisignRootCA.txt,default.cacert.pem,SMdefault.cacert.pem"SECURITY: +06:30 2014 509 1 .TEL | 0 CSecurityUtils::GetTrustedCertChain - Adding 6 certs to SSL_CTX cert store\n ->Phone add all the certificate to the TRUSTCERTS SECURITY: +06:30 2014 294 1 .TEL | 0 ProcessCertificates: END\n Process certificate mechanism finished by phone.
Slide68Trust Store
The
certificate validation
mechanism TLSSRVRID provides
increased security by allowing the client to validate the server’s identity and protect against man-in-the-middle attacks. Much like a person checking that the photo on a passport matches the appearance of the person carrying it.
File Service
(Utility Server)
Certificate
Validation (
Deskphones
)
HTTPS/PPM
HTTPS
SIP/TLS
XXXXXXX
Identity
Certificate
Avaya
Aura SM
XXXXXXX
Identity
Certificate
For HTTPS
c
onnection, the Identity Certificates
Subject Alternative Name
or the Common Name must match
the
FQDN
or IP
address of this connection
For SIP-TLS connections, the Identity Certificates Subject
Alternative
Name (dnsName) or the Common Name must match the SIP Domain of the Set.
Certificate Expiration date validation
requires a
valid source of
time (SNTP)
Slide69Trust Store
Certificate
Authority
SCEP/HTTP
Staging
Area
If 802.1x is enforced
Identity
Certificates
(
Deskphones
)
Certificate renewal
procedures will
be automatically initiated according to %
of
a certificate's Validity
interval
PKCS12
file
Download using HTTP or HTTPS (H.323 R6.6)
Simple Certificate Enrollment Protocol (SCEP) is an automated method to install and manage identity certificates.
The
terminals
generate a private
and public key pair
locally and create
a certificate signing request (CSR). SCEP is used to transmit the CSR with the public key to the CA. A successful response includes a signed identity certificate.
SET TRUSTCERTS < CA root
certificates
Slide70Troubleshooting for download of third party certificate on 96x1 Deskphone
Phone boot up process and requesting CA using SCEP for its own identity certificate. UI indication where third party certificate download fails.
Slide71For certificate related logs, below are Log categories that need to be enableSECURITY This is for certificate related issueHTTP Down load of file from HTTP serverENCRYPT Encrypted related issueCALENDER Issue if cleaner integration failSYS LOG 148.147.195.67 SECURITY: +06:30 2014 264 1 .TEL | 0 ProcessCertificates: START\n - > This message show while phone start process to down load the certificate to TRUSTCERTSSECURITY: +06:30 2014 271 1 .TEL | 0 ProcessCertificates: Add CMT_STATE_TRUSTED_CERT\n - >Phone start to add certificate to its TRUSTCERTS directory.SECURITY: +06:30 2014 281 1 .TEL | 0 PopulateEnrollList: SCEP URL not specified, bypassing enrollment\n -- >Administrator has not set ##SET MYCERTURL http://148.147.171.218/certsrv/mscep/mscep.dll in phoneSECURITY: +06:30 2014 281 1 .TEL | 0 PopulateEnrollList: SCEP URL not specified, bypassing enrollment\n -- >Phone by pass SCEP URL SECURITY: +06:30 2014 285 1 .TEL | 0 ProcessCertificates - Unblock CMT_STATE_WAIT m_bMyCertWait=0.\n -- > Pone will not start wait process in order to download the certificate vi SCEPSECURITY: +06:30 2014 498 1 .TEL | 0 Process trusted certificate done\n Phone done process certificate.SECURITY: +06:30 2014 509 1 .TEL | 0 CSecurityUtils::GetTrustedCertChain - Adding 6 certs to SSL_CTX cert store\n Phone store certificate onto TRUSTCERTS directory.As phone has 6 certificate phone will set all those in trusted directory SET TRUSTCERTS "AvayaITRoot2039.pem,smgr_ca.txt,av_sipca_pem_2027.txt,VerisignIntermediateCA.txt,VerisignRootCA.txt,default.cacert.pem,SMdefault.cacert.pem"SECURITY: +06:30 2014 509 1 .TEL | 0 CSecurityUtils::GetTrustedCertChain - Adding 6 certs to SSL_CTX cert store\n ->Phone add all the certificate to the TRUSTCERTS SECURITY: +06:30 2014 294 1 .TEL | 0 ProcessCertificates: END\n Process certificate mechanism finished by phone.
SYS LOG analysis when
no
SCEP URL given in phone 46xx settings
file
Slide72Endpoint Authentication
Avaya
Aura SM
Very Secure CA
Signed by:
Very Secure
Root Certificate
HTTPS ((PPM)/TLS (SIP))
XXXXXXX
Signed by:
X
Identity Certificate
Avaya
Aura SM
Very Secure CA
Signed by:
Very Secure
Root Certificate
HTTPS ((PPM)/TLS (SIP))
XXXXXXX
Signed by:
X
Identity Certificate
SBC
Mutual Authentication Enabled
An
Identity certificate
may
be
configured to
identify
an Endpoint when
requested
by the server
during the TLS handshake
stage and the Server must
have the corresponding trusted certificate to be able to verify
the Endpoints Identity Certificate
Avaya Communicator Lync 6.4
, One-X C and 96x1SIP support Endpoint Certificate validation
MSFT CERTMGR
Slide73TLS Mutual Authentication for SIP DevicesSoft Mutual Authentication
In Aura FP4, even if endpoint certificate validation is turned on in Session Manager Administration, SM does not require that the endpoint provides a certificate.Current SM implementation is "soft" authentication, endpoint certificate is validated only if provided.When Mutual Authentication is enabled SM requests the SIP Endpoint to present its certificate.SM will validate the Certificate and allow the communication with that Endpoint to proceed only if the validation is successful.If the SIP Endpoint does not present a certificate, SM will let the communication to proceed.
Slide74Enforce “Hard” Mutual Authentication is being added in the SM FP1 (7.0.1) Release.
Administrative capability is being added to strictly enforce SIP Endpoint certificate validation. If Endpoint TLS Certificate validation is set to “Required”, SM will not allow the communication with the SIP Endpoints to continue until the endpoints presents a valid certificates.
TLS Mutual Authentication for SIP DevicesHard Mutual Authentication
Slide75CM always request the certificate from the set. If “Mutual authentication” is “n” and the phone did not return certificate then TLS connection is established.If “Mutual authentication” is “n” and the phone did return certificate then the certificate is validated. If valid then connection is established, else TLS connection is closed. If “Mutual authentication” is “y” and the phone did not return certificate then TLS connection is established, but then CM will reject the connection using RRJ message. If “Mutual authentication” is “y” and the phone did return certificate then the certificate is validated. If valid then connection is established, else TLS connection is closed.
Support of H.323 signaling/registration over TLS
Slide76Endpoint Certificate Management without SCEP
XT Endpoints do not support SCEP. Certificate Signing Request (CSR) including transfer of the Signed Certificate and Trusted Certificate is manual process via the XT Endpoint Administration.
The Avaya B179 Conference Phone does not support SCEP or a CSR capability.
The
Trusted Certificate
, CA signed identity certificate and the private
key needs
to be
extracted from
the CA generated PKSC12 file
and
loaded separately via
Web
interface to the
B179
Slide77How to rollout Certificates to UC Clients ?
Avaya Communicator and one-X Communicator will leverage the Windows trust store built into the OS to establish a secure TLS connection for communications through SIP, PPM, XMPP, HTTPS, LDAP.
The Certificate authority that issued your server certificates must be trusted by the client devices. Action is required if servers are using certificates signed by a certificate authority that are not trusted by default in the device OS. In this scenario, the appropriate certificates must be distributed to the clients.
An end user
leveraging the certificate
import wizard or an administrator via Group Policy Objects for managed Pc´s can import a Trusted Certificate to the Windows certificate store under the “Trusted Root Certificate Authorities” folder.
Use
a Mobile Device Management solution to deploy the CA certificate to enrolled user devices
CA
certificate
is available on
an internal web page
and users are directed to download
the certificate to their devices.
Send the CA certificate via email to users and direct users to install the certificate on their devices
Avaya Settings Text File “Trustcerts” Parameter. Available for AC Android. Future for iOS Communicator Client line.
Slide78How to Install CertificatesStep 1 - Network Survey
Do
a survey of all of the affected network elements and their interconnections. Focus on elements that face the clients and the external network:
Avaya Aura Session Manager (including PPM)
Avaya Session Border Controller for Enterprise
Avaya Aura Conferencing (including web conferencing and document servers)
Avaya Identity Engines (including Realm Mapper service)
Avaya Client Enablement Services
Avaya Multimedia Messaging
Avaya Presence Server
Utility
Server
Enterprise
directory server
You may also have additional third-party network elements participating in your network. Identify the interconnections between these elements and the rest of the network. As part of this survey, capture the software release number of each network element, including all of the clients and phone sets.
In your network survey, make note of all certificates used. Many network elements will have more than one certificate, and each certificate may have slightly different characteristics depending on the type of service. See Certificate reference on page 9 for a detailed description of the required attributes for each type of certificate.
Slide79Step 2 - Site Evaluation
Identify
any elements of the network that need to be upgraded to support your new certificates. Some older versions of server software does not support replacing certificates.
If
you are using certificates of any length with SHA-2 digests, you should ensure you upgrade to a software release that supports SHA-2.
Consult
the product documentation for each of the elements in your network, including client applications and desk phones, to determine whether the installed software release supports the certificates you plan to install.
It is important to note that you need to validate that
both ends
of each communication link support the certificates you plan to install.
For
example, if you install a SHA-2 identity certificate on the Avaya Aura Session Manager “Security Module SIP” service, then all of the network elements which connect directly to the Avaya Aura Session Manager (in the diagram above: Avaya Aura Communication Manager, Avaya Media Server, Avaya Messaging Server, Avaya Client Enablement Services, Avaya Aura Conferencing, Scopia, Avaya Presence Server, all SIP desk phones, and all SIP soft clients) must support SHA-2.
Slide80Step 3 - Deployment
Deploy
CA certificates throughout your network for the new certificate
authority (CA)
Ensure
that the
CA issuing
your identity certificates is trusted throughout your
network
by installing
the CA certificate into the trust stores on all of the network elements, including devices running client applications and desk phones. Instructions for updating the trust stores on each network element are detailed in the product
documentation for
each network element.
If you
use
a well-known trusted third-party
CA
that is already supported by the devices running client applications, you will not need to deploy the CA certificate to these devices. However, you may still need to deploy the CA certificate to the servers and desk phones in your network.
Note: Many network elements have multiple trust stores. Ensure that you install the new CA certificate(s) in all of the required trust stores.
Deploy new server certificates
Updates
start at the “periphery” of the network and move towards the core elements. When planning your update, identify the network elements with the fewest incoming links and start there. On each server, install the new server identity certificate and verify that all connections to the server are functioning properly. Instructions for updating the server identity certificate on each network element are detailed in the product documentation for each network element.
Note: Each server may have multiple service interfaces. Ensure that you install the appropriate new server certificates for each service interface.
Remove support for the old CA certificate from your network
Once
you have validated that your updates are complete
+
all elements are using certificates from your new
CA,
you should remove trust for the old certificate authority. Instructions for updating the trust stores on each network element including the desk phones are detailed in the product documentation for each element.
Caution: Do not remove support for the old CA certificate from your network until the new CA certificate has been successfully installed and tested. Removing the old CA certificate prematurely can result in service outages.
Slide81Certificate Reference
I
n
general, certificates should comply with RFC 5280 and current NIST recommendations, including:
Using a recommended key algorithm;
Using a recommended key length;
Using a recommended message digest algorithm to create the certificate signature.
At time of writing, the current NIST recommendations were available at:
http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
There are several classes of certificates used within the Avaya Unified Communications solution portfolio:
Web services (server) – used by the Avaya Realm Mapper, Avaya Aura Conferencing web conferencing and document server, Personal Profile Management (a service on the Avaya Aura Session Manager), Avaya Multimedia Messaging, and the Utility Server, as well as various management interfaces.
SIP server – from a client perspective, the primary concern is the Avaya Aura Session Manager; however from a solution perspective many network elements have SIP connections to the Avaya Aura Session Manager.
XMPP server – primarily between clients and the Avaya Aura Presence Server for instant messaging, however there are other elements which use XMPP to connect with the Avaya Aura Presence Server.
LDAP server – while your enterprise LDAP server is not technically part of the Avaya Unified Communications solution, a number of clients and network elements are able to connect to your enterprise LDAP server for directory information.
“Generic” – this catch-all category encapsulates the Avaya one-X Client Enablement Services Handset Server as well as many internal management interfaces within the solution.
Slide82Certificate Reference Continued
Most certificate vendors and the Avaya Aura System Manager interface provide a streamlined process for obtaining standard certificates. If you use this streamlined process, you must make sure of the following minimum requirements:
The Subject Common Name field must include the fully-qualified DNS domain name of the server.
The key algorithm and key size are compatible with your security policy
The Subject Alternative Name field must have the following entries:
ipAddress – must have the IP address of the server
dNSName – must contain the fully-qualified DNS domain name of the server
dNSName – if the certificate is used for a SIP service, it must contain a dNSName entry containing the SIP domain being used. If multiple SIP domains are in use, you must have one dNSName entry for each SIP domain.
uniformResourceIdentifier – if the certificate is used for a SIP service, it must contain a uniformResourceIdentifier entry containing the SIP domain being used. If multiple SIP domains are in use, you must have one uniformResourceIdentifier entry for each SIP domain.
Wildcards are not supported for SIP domain entries.
Slide83Example: Web service (server) certificates
AttributeValueRequired?SubjectCN={fqdn}requiredValidityvalidity periodrequiredAuthority Key Identifierhashrequired1Subject Key IdentifierhashrecommendedSubject Public Key Infopublic key algorithmrequiredpublic key datarequiredSignaturesignature algorithm requiredsignature value requiredKey UsagedigitalSignatureoptional2nonRepudiationoptional2keyEnciphermentoptional2dataEnciphermentoptional2Extended Key Usageid-kp-serverAuth = 1.3.6.1.5.5.7.3.2.1requiredid-kp-clientAuth = 1.3.6.1.5.5.7.3.2.2optional3Subject Alternative NameIP:{ip}optional4DNS:{fqdn}required5Authority Information AccessOCSP - URI:http://{ocsp-server}{:ocsp-port}{/ocsp-path}optionalCRL Distribution PointsURI:http://{crl-server}{:crl-port}{/crl-path}optionalURI:ldap://{crl-server}{:crl-port}{/crl-dn}optional
1
authority
key identifiers are required elements in end entity certificates to establish a trust chain.
2
values may vary as specified in RFC 5280 and RFC 3279.
3
required if the same identity certificate is used when the server is acting as a client.
4
for the 96xx endpoints, PPM is "always" defined as an IP address, so PPM certificates must contain the
IP:{ip}
Subject Alternative Name entry when these endpoints are part of the solution.
5
if the
CN
field of the Subject contains the fully-qualified domain name of the server, then the
DNS:{fqdn}
entry in the Subject Alternative Name is optional.
Web service certificate
references
RFC
2818 (2000), HTTP Over
TLS
Special notes
Wildcard
name matching is defined in RFC 2818
Slide8484
CA Hierarchies
CAs can certify other CAs or “end entities”Certificates are links in a tree of EEs & CAs
CA
EE
RootCA
CA
EE
CA
EE
Slide85Febuary 21, 2006
85
Does Alice trust Bob’s Key?
Alice trusts Bob’s key if there is a chain of certificates from Bob’s key to a root CA that Alice implicitly trusts
CA
EE
RootCA
CA
EE
Root CA
CA
Root CA
Root CA
Slide86Chain Building & Validation
“Given an end-entity certificate, does there exist a cryptographically valid chain of certificates linking it to a trusted root certificate?”
CA
EE
RootCA
CA
EE
Root CA
CA
Root CA
Root CA
Slide87Chaining Certificates
In theory, building chains of certificates should be easy
“Just link them together like dominos”
In practice, it’s a lot more complicated...
Slide88Chain Building Details (1)
CA2
CA1
EE1
RootCA
EE2
CA2
EE3
Root CA
CA1
Root CA
CA2
CA1
EE2
CA1
EE1
EE3
Slide89February 21, 206
89
Chain Building Details (2)
CA2
CA1
EE1
RootCA1
EE2
EE3
Root
CA2
Slide90Chain Building Details (3)
CA2
CA1
EE1
Root
CA1
EE2
EE3
Root
CA2
Slide91Chain Building Details (3)
CA2
CA1
EE1
Root
CA1
EE2
EE3
Root
CA2
Bridge
CA
Slide92Chain Building Details (3)
CA2
CA1
EE1
Root
CA1
EE2
EE3
Root
CA2
Bridge
CA
Slide93February 21, 2006
Practical Aspects of Modern Cryptography
93
Chain Building Details (3)
CA2
CA1
EE1
Root
CA1
EE2
EE3
Root
CA2
Bridge
CA
Slide9494
Chain Building Details (3)
CA2
CA1
EE1
Root
CA1
EE2
EE3
Root
CA2
Bridge
CA
Slide95The X.500 Directory Model
The model SSL/TLS uses, the X.509 certificate model, is based on names
Names as principles
Specifically, X.509 is based on the X.500 directory model
X.500 defined a global, all-encompassing directory, to be run by the telcos
One directory to rule them all, one directory to define them...
Slide96ebruary 21, 2006
X.500 Distinguished Names
In the X.500 model, everything has a single, unique, global, assigned nameThere is a worldwide hierarchy, and you’re in it!
Slide97DNs in Practice
Name is unique within the scope of the CA’s name
Public CAs (e.g. Verisign) typically set
C = CA Country
O = CA Name
OU = Certificate type/class
CN = User name
E= email address
Slide98Private-label DNs
If you own the CA, you get to decide what fields go in the DN
Really varies on what the software supports
Can get really strange as people try to guess values for fields that are required by software
Software requires an OU, we don’t have OUs, so I better make something up!
Slide99DNs in X.509 Certificates
The X.509 certificate standard began as a way to associate a certificate with a node in the directory.
How is the subject of a cert identified?
By its DN.
How is the issuer of a cert identified?
By its DN.
How are certificates linked together?
By DNs.
Slide100Key fields in a certificate
The core fields of an X.509 certificate are
The subject public key
The subject Distinguished Name
The issuer Distinguished Name
What’s missing here?
The issuer’s public key is
not
present in the certificate.
You can’t verify the signature on the cert without finding a parent cert!
Slide101February 21, 2006
Practical Aspects of Modern Cryptography
101
Back to Chain Building
OK, assume we’re a “relying party application” -- something that received an end-entity certificate and wants to verify it.
Our task is to build a cert chain from that end-entity cert to one of our trusted roots
How do we do that?
We start with our EE cert, and using the information contained within we look for possible parent certificates.
Slide102February 21, 2006
Practical Aspects of Modern Cryptography
102
Parent certs
What’s a valid parent certificate?
In the raw X.509 model, parent-child relationships are determined solely by matching Issuer DN in the child to Subject DN in the parent
Recall that there’s an assumption that you have a big directory handy to find certs.
If you don’t have a directory handy, you need to do the matching yourself
This is not as easy as you might think…