MQTC v2015-SSL-TLS Using and Managing Certificates

SSL Certificate Management
or
What in the heck am I getting myself into!
Capitalware's MQ Technical Conference v2.0.1.5

Table of Contents
 What is SSL and TLS?
 What do SSL and TLS do (and not do)?
 Keystore and Certificate Lifecycle
 Certificates
 Certificate Management
 Certificate Management Tools

What is SSL & TLS?

SSL & TLS Terminology & History
 Terminology
N – Secure Socket Layer (SSL) - A communications protocol
– Transport Layer Security (TLS) - A communications protocol
– X.509 - Public Key certificate format standard
– WMQ Supports both SSL 3.0 and TLS protocols
O – TLS protocols are commonly, and incorrectly, referred to as SSL
 History
– X.509 introduced in 1988
– Developed by the International Telecommunications Union (ITU)
T – SSL introduced in 1994
– Developed by Netscape to support their HTTPS protocol
– Versions 1.0, 2.0. 3.0 Transport Layer Security (TLS) introduced in 1999
– Developed by the Internet Engineering Task Force
E – Extended SSL Version 3.0
– Versions 1.0, 1.1, 1.2, 1.3 (Draft)
– Each of these versions (both SSL and TLS) is a different protocol
– These versions do not interoperate!

The Problem perceived by Netscape
 What’s wrong with this picture?

– Transmission of sensitive information over an unsecure network (e.g. WWW).
– Is it really IBM on the other side?

Use of X.509 Certificates to encrypt the data
 OK. Better. But you’ve got me worried. Is it really IBM on the other side?
– The sensitive data has been encrypted.
– The destination has not been authenticated.

Use of Certificate Authorities for trust
 OK. Fine. I’m ready to send my confidential data.

– The sensitive data has been encrypted.
– The destination has been authenticated.

Asymmetrical Encryption
 X.509 encryption is based upon a complicated mathematical algorithm.

– This is a just a trivial example to demonstrate the mechanism.
– Each character in the incoming message is actually an 8 bit number (0 – 255).
– In this example, the encoding is in ASCII.
– The public (encryption) key is added to each character.
– The private (decryption) key is also added to each character.

How does the Magic work?
 X.509 Certificates are used with key pairs
– Public Key, stored in the certificate, used to encrypt incoming transmissions
N
– Private Key, stored in keystore and associated with certificate, decrypts incoming transmissions
– Private Key decrypts Public Key and vice versa
– Certificates signed by a trusted Certificate Authority (CA)
O  Public Key Exchange is handled by the protocol

– This is what SSL, and then TLS, were designed to do
o Each side exchanges it’s public key with the other side.
o Each side may then encrypt traffic being sent to the remote partner
T o The protocol (SSL/TLS) manages the key exchange transparently to the user
 Private Key distribution

– Web Sites (e.g. IBM.com) using SSL/TLS will generate a public/private key pair and obtain a
certificate from the CA using the public key
E
– Web Browsers (IE, Safari, Chrome, Firefox)
o Use generic key
• Provided by the Operating System vendor as part of the OS distribution
S • Used for encryption, does not provide any authentication to merchant
o Embedded Certificate Authority Public Certificates (All major CA certificates are installed)

How does the Magic work? (continued)
 Do you trust the Certificate Authority?
N – Consumers don’t know anything about certificates and Certificate Authorities
– However, software vendors such as Microsoft and Apple do.
– The software vendors make this choice for the consumers by preloading CA Public Keys
– Every major CA Public Key is loaded into the Truststore used by the Browser
O
 What is the Certificate Authorities function?
– To ensure that the attributes of the certificate match the source requesting the certificate.
o For example,
T • The Common Name (or SAN DNS) domain matches the requestor’s domain
• For example, an IBM.COM certificate should only be issued to an administratively
responsible person within IBM.
• This involves restricting and registering administrators allowed to request certificates for
a domain and verifying certificates are requested from the authorized e-mail addresses.
E

TLS Summary
 SSL was originally developed by Netscape
– Goal was to enable electronic payment over the WWW.
 TLS encrypts communications between two partners

– Transmissions are encrypted in both directions over the life of the session.
– Encryption is managed through X.509 Private certificates being present at both ends
– Authentication is managed by having the Public Portion of each of the signing CA certificates
be present at the opposing end.
 Client Browser validates URL against Private Certificate of website

– Personal certificate must contain the URL or generic domain of the URL
– Personal certificate must be signed by a CA certificate known to the browser
 Server does not validate client Private Certificate by default

– No reason to deny access to someone who wants to purchase from you!
 Servers, and hence browsers, are preloaded with certificates

– Generic personal certificate
– All major CA Signer Certificates (Public Portion)
– Entire process transparent to Browser user

What does TLS do (and not do)?

What TLS does do (normally)
 Encrypts traffic in both directions

– This is essential for sensitive data transmitted over the web
– This may not be relevant to server to server communications within a Data Center
– TLS connections can be configured to not use encryption
o NULL_MD5, NULL_SHA (SSL 3.0)
o TLS_RSA_WITH_NULL_SHA256, TLS_RSA_WITH_NULL_NULL (TLS 1.2)
o ECDHE_RSA_NULL_SHA256, ECDHE_ECDSA_NULL_SHA256 (TLS 1.2)
 Validates server identity to the client

– The client validates the server’s certificate against the clients Truststore to ensure that the client
trusts the identity of the server because the client trusts the signer of the certificate. This is
what is called the “web of trust”.
– This is useful for internet financial traffic; you want to know where your money is going
– This is useful in a data center to protect against “spoofing” a server

What TLS does not do (normally)
 Validate client identity to the server
– Since this is the primary reason we use SSL/TLS in WMQ, this is a major problem.
o However, WMQ can be configured to force client authentication on channels
o SSLCAUTH (REQUIRED)
 Deny access to the server

– Since this is the primary reason we use SSL/TLS in WMQ, this is a major problem.
o However, WMQ can be configured to restrict incoming certificates
o SSLPEER (‘O=IBM, OU=SWG, OU=ISSW’) or SET CHLAUTH
• SSLPEERMAP SSLPEER (‘O=IBM, OU=SWG, OU=ISSW’) USERSRC(CHANNEL)
o Note that this requires X.509 certificates to have reasonable Distinguished Name fields
 If you’re not doing both of these things, then maybe you should be!
– One of the primary uses of SSL/TLS within WMQ is to authenticate clients!
– If you have encryption turned on, are you also using ALS to protect your messages on disk?

SSL/TLS Summary for WMQ
 SSL or TLS can be used to encrypt traffic between two servers
 SSL or TLS can be used to assert the identity of each of the two servers
– Identity checking of the client must be requested - SSLCAUTH (REQUIRED)
– Each server must posses a Personal Certificate in their Keystore
– Each server must posses the signer certificates of the remote server in their Truststore
– Note that what is being authenticated is the identity of the server, not the User ID initiating the
SSL/TLS connection!
 Neither SSL nor TLS deny access at the protocol level by default
– However, WMQ requires certificates to be trusted (i.e. their signer in your Truststore)
– “Filtering” of certificates performed implicitly by the Truststore
– ”Filtering” of certificates may also be performed explicitly - SSLPEER
 Neither SSL nor TLS deny provide Access Control

– They are Encryption and Authentication mechanisms
– WMQ can provide Access Control based upon the authentication
– MCAUSER(userID)

Keystore and Certificate Lifecycle

Terminology - 1
 Keystore
N – A encrypted and password database to store X.509 certificates & Private Keys
– Multiple formats for Keystores
o CMS (Content Management System)
o JKS (Java Key Store)
O o JCEKS (Java Cryptographic Extension Key Store)
o PCKS #12 (Public Key Cryptography Standards)
– Keystores may contain
– Certificate Signing Requests (CSR)
T – Personal Certificates (Issued by a CA or self-signed)
– Private Keys associated with a Personal Certificate
– Signer Certificates (Downloaded from a CA or Extracted from a Self-Signed certificate)
 Truststore
E – Two different, but related, meanings:
o As a file; a specialized Keystore used to only store Signer certificates
o As a function; the portion of the Keystore file that contains Signer certificates
– Separate Truststore files are ot used by all software
S – Separate Truststore files simplify certificate management

Terminology - 2
 Certificate Signing Request (CSR)
N – A request for a personal certificate generated by a key tool and formatted as a CSR.
– The CSR is formatted as an encoded text string and may be manipulated as a text string.
– The CSR is transmitted to a Certificate Authority.
– The CSR does not contain the Private key. This key remains with the Keystore.
O
 Certificate Response File
– The response (Certificate) from a CA to a Certificate Signing Request.
– The response is an encoded text string similar to a CSR and may be manipulated as a text string.
T – This certificate does not contain the Private key. This key still remains in the Keystore from which
the CSR originated.
 Personal Certificate
– An X.509 certificate asserting the identify of a URL, Server, or person.
E – Contains the Public key and associated with a private key through the Keystore.
– Either Self-signed or issued by a Certificate Authority.
– Multiple formats for certificates:
– ARM, DER, PEM, PKCS #7, & PKCS #12.
S – Certificate formats containing a private key are password protected.

Terminology - 3
N  Signer Certificate
– An X.509 certificate used for authenticating another certificate
– Either Self-signed or issued by a Certificate Authority.
– Contains only the Public Key of the Signer Certificate.
O
 Public Certificate
– The Certificate issued by a CA (containing Public but not Private key) in response to a CSR.
– A subset (Signer portion) of a Self-Signed Personal Certificate containing only the Public Key.
T – This certificate is exchanged during the SSL handshake.
– These Certificate formats do not require a password.
 Private Key
E – The private (secret) part of a Public/Private key pair.
– Created when a CSR is generated and stored in the Keystore from which the CSR originated.
– Associated in a Keystore with a Public Certificate when the Certificate is “Received” from the
CA.
S

Keystore Lifecycle
 1) Create a Keystore
 2) Request a Personal Certificate
 3) Transmit CSR to CA
 4) CA transmits CSR Response
 5) Receive response into Keystore
 6) Download signer certificates from
CA
 7) Add or Populate Signer certificates
into Keystore
 8) Export Personal certificate (if
necessary to deploy certificate to
remote Keystore)

A Note on Passwords
 All Keystore and Truststore formats require a password
 All Personal Certificate formats containing private keys require a password
 This can add up to a lot of passwords

– Some form of password management is needed
 These passwords must be supplied when opening a Keystore or Certificate

– Can be entered interactive by human users
– Can be stored in a file for use by software (e.g. WMQ)
– This is called a “Stash” file

Keystore Summary for WMQ
 Some software has built-in software to manage Keystores / Truststores
– WebSphere
 Some software requires external software to manage Keystores / Truststores

– WebSphere MQ
– WebSphere Message Broker / IBM Integration Bus
– Multiple certificate management software options
o iKeyMan (IBM Key Manager)
• gsk7cmd, gsk7capicmd, gsk8cmd, gsk8capicmd
o Keytool (Oracle Java)
o OpenSSL
 Multiple Keystore/Truststore formats

– CMS, JKS, JCEKS, PCKS #12
– WMQ requires CMS format Keystores
– WebSphere and Message Broker require JKS Keystores
– WebSphere Message Broker optionally uses a separate Truststore
 Keystores / Truststores may be built in place or transmitted

– Built and stored on server where they will be used (requires a Key Tool such as iKeyMan)
– Built centrally and securely shipped to destination server

Certificates

X.509 Common Certificate Fields
 DN (Distinguished Name)
o CN (Common Name)
– Name certificate represents (e.g. “Capitalware”)
– Name certificate represents (e.g. “www.capitalware.com”)
– What you see in your browser when you click on a certificate
o O (Organization)
– Name certificate represents (e.g. “Capitalware”)
o OU (Organizational Unit)
– Hierarchy within organization (e.g. “OU=Education”, “OU=MQTC”)
o L (Locality)
– Geographic Location or City (e.g. “Sandusky”)
o ST (State)
– State of Locality (e.g. “Ohio”)
o C (Country)
– Country of Locality (e.g. “US”)
 SAN (Subject Alternative Names)

– E-mail, IP, or DNS names that are aliases of the Common Name (CN)

X5.09 VeriSign certificate in iKeyMan
 iKeyMan tool (IBM Key Manager)
 Display of a VeriSign Intermediate
Signing certificate.
 Note the Serial Number. It is this
field, and not the Common Name
(CN) that uniquely identifies this
certificate!
 Note the Fingerprint (also referred to
as Thumbprint or Digest). It is this
field that identifies this certificate in
the signing chain!

Certificate Signing Chain in DigiCert
 DigiCert tool
 Displays the signing chain for a
certificate. In this case, the certificate
is for “wcas135.chemd.net”.
 Note this (wcas135.chemd.net) is a
public server that can be found using
“nslookup”.
 The certificate with the Common
Name of “wcas135.chemd.net” was
signed by an Intermediate VeriSign
certificate with the Common name of
“VeriSign Class 3 Secure Server CA –
G3”.
 The Intermediate VeriSign certificate
was signed by a root VeriSign
certificate.

 DigiCert tool
 Displays information about the
“VeriSign Class 3 Secure Server CA –
G3” certificate.
 Note this “Intermediate
Signer”certificate was signed by the
“VeriSign Class 3 Public Primary
Certification Authority – G5” “Root
Signer” certificate.
 Now lets look at the certificate details.

 DigiCert tool
 Note the Serial Number of the
certificate.
 If a remote server needed the Signer
certificate for “wcas135.chemd.net”,
they would need to ensure that they
certificate they imported into their
Keystore had this Serial Number.
 Important Note: You must ensure the

Serial numbers are correct for your
Signer certificates! Some of the
Certificate Authorities have multiple
certificates with the same Common
Name!

Certificate Labels
 iKeyMan tool (Personal Certificates)

 The names displayed are Labels, not Common Names (CN)
 The asterisk (“*”) denotes the “Default” certificate for the Keystore

Using Certificate Labels
 If there is more than one Personal Certificate, which one should be used?
– There are three mechanisms.
o Restrict the Keystore to containing exactly one Personal Certificate
• No possible confusion
• Not as flexible
 This is the mechanism used by WMB/IIB
o Use the “Default” certificate
• Requires a Personal Certificate to be identified as the “Default” certificate
• Easy to make mistakes
o Find the certificate by its label
• No possible confusion
• Requires certificates to be identified by a specific label
 This is the mechanism used by WMQ
• ibmwebspheremqqmgrname (All in lower case)
– These mechanisms are part of the APIs used to access the Keystores
– The software accessing the Keystore determines the method to use

Certificate Summary for WMQ
 WMQ needs to know where the Keystore is located
– Queue Manager parameter SSLKEYR
o Specify the path and filename, but the file extension (“.kdb”)
 WMQ requires that Keystore be in the CMS format

– Stored as multiple files
o Keystore file required (must have the ”.kdb” file extension)
o Keystore file required for CSRs (must have the “.rdb” file extension)
o Password Stash file required (must have the “.sth” file extension)
– All files must have the same name, with a differing file extenstion!
 WMQ requires the certificate to have a specific label in the Keystore

– ibmwebspheremqqmgrname
 WMQ does not care about any of the fields in a certificate

– Unless the SSLPEER parameter is set!

Certificate Management

Certificate Management Steps
1) Build Keystores and Truststores (One for every server)
– Build at one location using central tool and distribute Keystores and Truststores to each server
– Build on each server using a tool on each server
– Create Stash files for each Keystore
2) Obtain Personal Certificates (One for every server)

– Generate CSRs to CA or create Self-Signed certificates
– “Receive” CA Response certificates into Keystore (marries Public Certificate to Private Key)
3) Added Signer certificates to Keystores

– Adding as few Signers as possible increases security
– Adding as few Signers as possible increases work (what Signers do I need)
– Add Signers for all expected incoming certificates (e.g. Certificates from remote servers)
– “Extract” Public portion (Signer) of Self-signed certificates
4) Distribute Keystores and Truststores to servers
5) Configure software to use SSL/TLS

iKeyMan Home Screen

iKeyMan New Keystore -1

iKeyMan New Keystore -2

iKeyMan Certificate Signing Request

iKeyMan Receiving Response from CA

iKeyMan Adding Signer Certificates

iKeyMan Populating Signer Certificates

Keystore Ready to Deploy!

Certificate Management Tools

Available Tools
 IBM Global Security Kit (GSKit)
– Multiple software versions
– Command Line
o gsk7cmd / gsk8cmd
o gsk7capicmd / gsk8capicmd
– GUI
o iKeyMan
 Java (Oracle)
– Versioned by Java software releases
– Command Line
o keytool
 Open Source
– Command Line
o openssl

Tool Caveats
Tools are not comprehensive
o Not all tools support all types of Keystores/Truststores
o Not all tools support all types of Certificate formats
o No tool supports multiple different software release versions
Tool usage
o The use of multiple tools may/will be required
o Check the software version of the tool for compatibility with the target software
Tool location
o Central location (your workstation?)
o On the servers with Keystores/Trustores
Security
o Certificate files
o Keystore and stash files

MQ Performance Tuning
Reference

SSL/TLS Components & Connections

WMQ Channel Processing

IIB SSL Components

WebSphere SSL Components

iKeyMan Files

SSL/TLS File Formats

Reference Links
 IBM Global Security Kit v8.0 (iKeyMan)
– IBM TechNote: AIX Installation
o http://www-01.ibm.com/support/docview.wss?uid=swg21577384
– IBM TechNote: Linux Installation
– IBM TechNote: Windows Installation
– IBM developerWorks: Managing Certificates using GSKit
o http://www.ibm.com/developerworks/security/tutorials/se-gskit
 TechDoc on Global Security Kit installation

– Contact me
 TechDoc on SSL/TLS
– Contact me

Questions & Answers

Presenter
 Glen Brumbaugh
– [email protected]
 Computer Science Background

– Lecturer in Computer Science, University of California, Berkeley
– Adjunct Professor in Information Systems, Golden Gate University, San Francisco
 WebSphere MQ Background (20 years plus)

– IBM Business Enterprise Solutions Team (BEST)
o Initial support for MQSeries v1.0
o Trained and mentored by Hursley MQSeries staff
– IBM U.S. Messaging Solutions Lead, GTS
– Platforms Supported
o MVS aka z/OS
o UNIX (AIX, Linux, Sun OS, Sun Solaris, HP-UX)
o Windows
o iSeries (i5OS)
– Programming Languages
o C, COBOL, Java (JNI, WMQ for Java, WMQ for JMS)


MQTC v2015-SSL-TLS Using and Managing Certificates

Uploaded by

Copyright:

Available Formats

MQTC v2015-SSL-TLS Using and Managing Certificates

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

MQTC v2015-SSL-TLS Using and Managing Certificates

Uploaded by

Copyright:

Available Formats

SSL Certificate Management

What in the heck am I getting myself into!

Capitalware's MQ Technical Conference v2.0.1.5

 What is SSL and TLS?

 What do SSL and TLS do (and not do)?

 Keystore and Certificate Lifecycle

 Certificate Management Tools

Capitalware's MQ Technical Conference v2.0.1.5

What is SSL & TLS?

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

 What’s wrong with this picture?

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

 OK. Fine. I’m ready to send my confidential data.

Capitalware's MQ Technical Conference v2.0.1.5

 X.509 encryption is based upon a complicated mathematical algorithm.

Capitalware's MQ Technical Conference v2.0.1.5

O  Public Key Exchange is handled by the protocol

 Private Key distribution

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

 TLS encrypts communications between two partners

 Client Browser validates URL against Private Certificate of website

 Server does not validate client Private Certificate by default

 Servers, and hence browsers, are preloaded with certificates

Capitalware's MQ Technical Conference v2.0.1.5

What does TLS do (and not do)?

Capitalware's MQ Technical Conference v2.0.1.5

 Encrypts traffic in both directions

 Validates server identity to the client

Capitalware's MQ Technical Conference v2.0.1.5

 Deny access to the server

Capitalware's MQ Technical Conference v2.0.1.5

 Neither SSL nor TLS deny provide Access Control

Capitalware's MQ Technical Conference v2.0.1.5

Keystore and Certificate Lifecycle

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

 All Keystore and Truststore formats require a password

 All Personal Certificate formats containing private keys require a password

 This can add up to a lot of passwords

 These passwords must be supplied when opening a Keystore or Certificate

Capitalware's MQ Technical Conference v2.0.1.5

 Some software requires external software to manage Keystores / Truststores

 Multiple Keystore/Truststore formats

 Keystores / Truststores may be built in place or transmitted

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

 SAN (Subject Alternative Names)

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

Capitalware's MQ Technical Conference v2.0.1.5

 Important Note: You must ensure the