Digital Certificate Demystified

Ross Cooper, CISSP®

IBM Corporation

August 2013
SHARE Session: 13651
Trademarks
The following are trademarks of the International Business Machines Corporation in the United States and/or other countries.
AIX*
BladeCenter* Domino* Language Environment* SYSREXX z10
BookManager* DS6000 MVS System Storage z10 BC
CICS* DS8000* Parallel Sysplex* System x* z10 EC
DataPower* FICON* ProductPac* System z zEnterprise*
DB2* IBM* RACF* System z9 zSeries*
DFSMS IBM eServer Redbooks* System z10
DFSMSdss IBM logo* REXX System z10 Business Class
DFSMShsm IMS RMF Tivoli*
DFSMSrmm InfinBand ServerPac* WebSphere*
DFSORT
* Registered trademarks of IBM Corporation
The following are trademarks or registered trademarks of other companies.
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.
IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Windows Server and the Windows logo are trademarks of the Microsoft group of countries.
ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Java and all Java based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.
Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom.
Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo are trademarks of HP, IBM Corp. and Quantum in the U.S. and other countries.
* Other product and service names might be trademarks of IBM or other companies.
Notes:
Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon
considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve
throughput improvements equivalent to the performance ratios stated here.
IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply.
All customer examples cited or described in this presentation are presented as illustrations of the manner in which some customers have used IBM products and the results they may have achieved. Actual environmental costs and
performance characteristics will vary depending on individual customer configurations and conditions.
This publication was produced in the United States. IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without notice. Consult your local IBM
business contact for information on the product or services available in your area.
All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.
Information about non-IBM products is obtained from the manufacturers of those products or their published announcements. IBM has not tested those products and cannot confirm the performance, compatibility, or any other claims related
to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
Prices subject to change without notice. Contact your IBM representative or Business Partner for the most current pricing in your geography.
This information provides only general descriptions of the types and portions of workloads that are eligible for execution on Specialty Engines (e.g, zIIPs, zAAPs, and IFLs) ("SEs"). IBM authorizes customers to use IBM SE only to execute
the processing of Eligible Workloads of specific Programs expressly authorized by IBM as specified in the “Authorized Use Table for IBM Machines” provided at www.ibm.com/systems/support/machine_warranties/machine_code/aut.html
(“AUT”). No other workload processing is authorized for execution on an SE. IBM offers SE at a lower price than General Processors/Central Processors because customers are authorized to use SEs only to process certain types and/or
amounts of workloads as specified by IBM in the AUT.

2
 Agenda

• Cryptography
• What are Digital Certificates
• Certificate Types and Contents
• Certificate Formats
• Certificate Validation
• Certificates and SSL
• Certificate Life Cycle

3
 Symmetric Encryption
• Provide data confidentiality
• Same key used for both encryption and decryption
• Fast, used for bulk encryption/decryption
• Securely sharing and exchanging the key between both parties is a major issue
• Common algorithms: DES, Triple DES, AES

Secret Key

Encryption Algorithm

Encrypted Message
Original Message

This is a plain text QWE@56!121!TQM

Decryption Algorithm

Same Secret Key

4
 Asymmetric Encryption
• Public / private key pairs - 2 different keys
• A public key and a related private key are numerically associated with each other.
• Provide data confidentiality, integrity and non repudiation
• Data encrypted/signed using one of the keys may only be decrypted/verified using
the other key.
• Slow, Very expensive computationally
• Public key is freely distributed to others, private key is securely kept by the owner
• Common algorithms: RSA, DSA, ECC
Private Key

Encryption Algorithm

Encrypted Message
Original Message

This is a plain text QWE@56!121!TQM

Decryption Algorithm

Public Key (related to the private key)

5
 Message Digest (Hash or Fingerprint)
• A fixed-length value generated from variable-length data
• Unique:
• The same input data always generates the same digest value
• Tiny change in data causes wide variation in digest value
• Theoretically impossible to find two different data values that result in the same digest
value
• One-way: can’t reverse a digest value back into the original data
• No keys involved – Result determined only by the algorithm
• Play a part in data integrity and origin authentication
• Common algorithms: SHA1, SHA256
Hash Algorithm
Digested Message
Original Message

I owe you $10,000 4E284BA3E947053267545B507A476B4A6538BAE7

Hash Algorithm

Totally different digested Message

Similar Message
5B0EBF53D5A30220BF68E88CCC04A4ACA3E9470
I owe you $10.000

6
 Asymmetric Encryption
(for confidentiality)
Encrypting a message:

Encrypt with Recipient’s

Public key
Sender: Msg

Decrypting a message:

Decrypt with Recipient’s

Recipient:
Private key
Keys:
Msg

Plain text

Encrypted text

7
 Signing (for integrity and non repudiation)
Encrypt with
Signing a message: Sender’s
Hash Private key
Sender: Msg

Msg + Signature

Verifying a message:
Decrypt With Sender’s
Recipient: Public key to recover the
hash

Do they match? If yes, the message is

Keys:
unaltered. Assuming the hashing
Plain text algorithm is strong.
Message digest Hash
Msg
Signature
 What is a Digital Certificate?

A Digital Certificate is a digital document issued

by a trusted third party which binds an end entity
to a public key.
• Digital document:
• Contents are organized according to ASN1 rules for X.509 certificates
• Encoded in binary or base64 format
• Trusted third party aka Certificate Authority (CA):
• The consumer of the digital certificate trusts that the CA has validated that the end entity
is who they say they are before issuing and signing the certificate.
• Binds the end entity to a public key:
• End entity - Any person or device that needs an electronic identity. Encoded in the
certificate as the Subjects Distinguished Name (SDN). Can prove possession of the
corresponding private key.
• Public key - The shared half of the public / private key pair for asymmetric cryptography
• Digitally signed by the CA

9
 What is a Digital Certificate?
• Best way to think of it is as an ID card, like driver licenses or passport
• To establish your identity or credential to be used in electronic
transactions
• Digital certificate technology has been in existence for over 20 years
• Packaging of the information is commonly known as the X.509 digital
certificate. X.509 defines the format and contents of a digital
certificate.
• IETF RFC 5280
• Have evolved over time to not only bind basic identity information to
the public key but also how public key can be used, additional identity
data, revocation etc.
• Generally a digital certificate provides:
• Identity to a person or a server
• Distribution of a public key

10
 How is Digital Certificate used?
• Prove Identity to a peer:
• Owner of the certificate can prove possession of the certificate's private key
• Identity can be validated by checking it is signed by a trusted Certificate
Authority
• Prove authenticity of a digital document:
• Programs can be signed by code signing certificates
• E-mail signatures
• Certificates are signed by CA certificates
• Establish a secure connection:
• Certificates contain a public key which allows protocols such as SSL and
AT-TLS to exchange session keys

11
 What is in a Digital Certificate?

Certificate Info Version 1, 2, 3

version
serial number
signature algorithm ID This is the hash/encrypt algorithm used in the
signature, eg. sha256RSA
issuer’s name

validity period The certificate binds a public key to a subject

subject’s name
Certificate
CA signs the above cert info by encrypting the
subject’sSignature
public key
hash with its private key
extensions

The private key is NOT in the certificate. It is kept

in a key store

You can NOT change ANY of the certificate information!

12
 Extensions of a X.509 Digital Certificate
• Adds additional definitions to a certificate and its identity information
• 15+ extensions currently defined
• Top 7 extensions of interest:
• Authority Key Identifier – Unique identifier of the signer
• Subject Key Identifier – Unique identifier of the subject
• Subject Alternate Name – Additional identity information
• Domain name • E-mail
• URI • IP address
• Basic Constraints – Certificate Authority Certificate or not
• CRL Distribution – Locating of Revoked certificate information
• Key Usage – Defines how the public key can used
• Digital Signature • Key Encipherment
• Key Agreement • Data Encipherment
• Certificate Signing • CRL signing
• Extended Key Usage – Further defines how the public key can be used
• Server Auth • Code Signing
• Client Auth • E-mail
• OCSP Signing • Timestamping

13
 Example of a x.509 Digital Certificate

14
 Digital Certificates and Certificate stores
• Certificate must be placed in a certificate store before it
can be used by an application, like communication Server
or HTTP server for secure communication

• On z/OS, many components call System SSL APIs, which

in turn call RACF R_datalib callable service to access the
certificate store
• Application → System SSL → R_DataLib

• Different names:
• Certificate store = key ring = key file = key database

15
 Types of Digital Certificates - Issuer
• Self Signed
• Self-issued
• Issuer and subject names identical
• Signed by itself using associated private key
• No trusted party involved – Must be implicitly trusted
• Common uses for self signed certificates:
• Root CA certificate
• Single trusted certificate

• Signed Certificate
• Signed/issued by a trusted Certificate Authority Certificate using its private key.
• By signing the certificate, the CA certifies the validity of the information. Can be
a well-known commercial organization or local/internal organization.
• Common uses for signed certificates:
• End entity certificates
• Intermediate CA Certificates

16
 Types of Digital Certificates - Usage
• Secure Socket Layer (SSL) Certificate
• Install on a server that needs to be authenticated, to ensure secure
transactions between server and client
• Code Signing Certificate
• Sign software to assure to the user that it comes from the publisher it claims
• Personal Certificate
• Identify an individual, enable secure email – to prove that the email really
comes from the sender and /or encrypt the email so that only the receiver can
read it
• More (name it whatever you want)…
• Wireless certificate, smart card certificate, EV Certificate…
• Certificate Authority (CA) certificate
• Used to sign other certificates
• Root CA: the top
• Intermediate CA: signed by root CA or other intermediate CA

17
 Digital Certificate Formats
• X.509 Digital Certificate can exist in many different forms
• Single certificate
• PKCS Package - (Public-Key Cryptographic Standards) –
Developed by RSA
• PKCS #7 certificate package
• Contains 1 or more certificates
• PKCS #12 certificate package
• A password encrypted package containing 1 or more
certificates and the private key associated with the end-
entity certificate.
• Only package type that contains a private key
• Can be in binary or Base64 encoded format
• Base64 is used to convert binary data to displayable text for
easy cut and paste
18
 Certificate Revocation
• Normally the lifetime of certificate is the defined validity period
• Revocation provides a means for a certificate to become invalid prior to
its validity end date
• Reasons for revocation:
• Private key associated with the certificate has been compromised
• Certificates are being used for purpose other than what they are
defined
• CRL – Certificate Revocation List:
• List of certificates that should no longer be trusted
• CRL Distribution Point extension in the X.509 certificate gives
information about where to locate revocation information for the
certificate.
• OCSP – Online Certificate Status Protocol:
• Provides a query function for the revocation status of a certificate

19
 Certificate Chain Validation

Is the root CA in my key ring ?

Finish
Self signed:
Issuer=Subject
Root CA
Issuer – CN=Root CA,OU=Signers,O=IBM,C=US
Subject -CN=Root CA,OU=Signers,O=IBM,C=US
…
Signature

Intermediate CA
Issuer - CN=Root CA,OU=Signers,O=IBM,C=US
Subject – CN=Intermediate CA,OU=Signers,O=IBM,C=US
…
Signature

End Entity
Issuer – CN=Intermediate
CA,OU=Signers,O=IBM,C=US
Subject -CN=Server Certificate,OU=z/OS,O=IBM,C=US
Start
…
Signature
20
 Certificate Validation
• Signature chain validation:
• End Entity certificate signature is validated by signer's public
key
• Any intermediate CA certificates signatures are validated
against their signer's public key
• Root CA certificate is validated against it's own public key
• Root CA certificate must be trusted
• Validity period – Check if the certificate has expired
• Status – Check if the certificate has been revoked:
• CRL - Check if it is on a Certificate Revocation List
• OCSP - Check with the CA which issued this certificate
through the Online Certificate Status Protocol

21
 Certificates in SSL handshake
1. Client sends a ‘hello’ msg to server
2. Server sends its certificate to client
3. Client validates the server’s certificate
4. Client encrypts a secret key with server’s public key and
sends it to server
5. Server decrypts the secret key with its private key
6. Server encrypts a ‘handshake OK’ msg with the secret key and
sends it to client
7. Client trusts server, business can be conducted
* Note the above steps illustrate server authentication. For
client authentication, server needs to validate client’s
certificate too.
Is CA
cert of Client Hello msg
Server
server
Certificate
cert Secret key
here? Server Cert
OK msg

Cert
Cert Encrypted Transactions store
store with the secret key
eg, RACF DB
eg, RACF DB

22
 Setup a certificate for SSL handshake
1. Create a key ring (aka key file / certificate store)
2. Install the CA certificates that will be used for SSL handshake
3. Generate a certificate signing request (also CSR)
• Like an application to a certificate authority to obtain a signed
digital certificate
• Contains info about on the requestor
• Identifying information, like subject name
• Public key (may be generated before the request or generated
at the same time as the request)
• Other credentials or proofs of identity required by the certificate
authority
• Corresponding private key is not included in the CSR, but is
used to digitally sign the request to ensure the request is actually
coming from the requestor

23
 Setup a certificate for SSL handshake

4.If the request is successful, the certificate authority will

send back an identity certificate that has been digitally
signed with the private key of the certificate authority.
5.Install the certificate to the key ring
6.Permit the application to access the key ring, the
certificate and its associated private key
• If it is a RACF key ring, use access control through
<ring owner>.<ring name>.LST in the RDATALIB class
• If it is a key file, permission is through the file system’s
permission bits and password

24
 Certificate Life Cycle
• To set up a certificate for secure traffic the first time is only the
beginning
• Must plan for the certificate life cycle
• Certificate expiration causes application outage
• Things to consider:
• How many certificates are actively used in the system?
• Certs locally created VS Certs by external provider
• How to keep track of the expiration dates of all the certificates in the
system?
• Spreadsheets?
• Utilities?
• Automation for renew?
• Use certificate management vendor products?

25
 Review
• Cryptography
• What are Digital Certificates
• Certificate Types and Contents
• Certificate Formats
• Certificate Validation
• Certificates and SSL
• Certificate Life Cycle

26
 References
• IBM Education Assistant web site:
http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/index.jsp
• RACF web site:
http://www.ibm.com/servers/eserver/zseries/zos/racf
• PKI Services web site:
http://www.ibm.com/servers/eserver/zseries/zos/pki
• IBM Redbooks
z/OS V1 R8 RACF Implementation
• Security Server Manuals:
RACF Command Language Reference
RACF Security Administrator's Guide
• Cryptographic Server Manual
Cryptographic Services System Secure Sockets Layer Programming
• RFCs
RFC2459 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile

27
 Questions?

Questions
or Time for Coffee ?

Ross Cooper
Session: 13651

28
 Backup Slides:
• RACDCERT Overview & Commands
• RACF Key Rings and Certificates
• Certificate Types and Contents
• PKI Services: Full Certificate Authority

29
 RACDCERT Overview
• RACDCERT is the primary administrative tool for managing digital
certificates using RACF.
• TSO command shipped as part of RACF
• Command line interface with ISPF panels
• Certificates and Rings are protected by
RACF profiles
• Learn more:
• RACF Command Language Reference

RACDCERT ID(FTPServer) GENCERT SUBJECTSDN(CN(‘Server

Certificate’)OU(‘Production’)O(‘IBM’)L(‘Poughkeepsie’) SP(‘New
York’)C(‘US’)) SIZE(1024) WITHLABEL(‘Server Certificate’)
ALTNAME(DOMAIN(‘mycompany.com'))
RACDCERT ID(FTPServer) ADD(‘user1.svrcert’) WITHLABEL(‘Server
Certificate’)
RACDCERT ID(userid) EXPORT (LABEL('label-name')) DSN(output-dataset-
name) FORMAT(CERTDER | CERTB64 | PKCS7DER | PKCS7B64 |
PKCS12DER | PKCS12B64 ) PASSWORD('pkcs12-password')

30
 RACDCERT Commands
• Certificate Generation:
• RACDCERT GENCERT – Generate key pair and certificate
• RACDCERT GENREQ – Generate a certificate request
• Certificate Installation:
• RACDCERT ADD – Install a certificate and public/private key
• Certificate Administration:
• RACDCERT LIST – Display certificate information from an installed
certificate
• RACDCERT ALTER – Change certificate installation information
• RACDCERT DELETE – Delete certificate and key pair
• RACDCERT CHECKCERT – Display certificate information from a dataset
• RACDCERT EXPORT – Export a certificate or a certificate and private key
• RACDCERT REKEY – Renew certificate with new key pair
• RACDCERT ROLLOVER – Finalize the REKEY process

31
 RACDCERT Commands
• Certificate Ring Administration:
• RACDCERT ADDRING – Create a key ring
• RACDCERT CONNECT – Place a certificate in a key ring
• RACDCERT REMOVE – Remove a certificate from a key ring
• RACDCERT LISTRING – Display key ring information
• RACDCERT DELRING – Delete a key ring

• Certificate Map Administration:

• RACDCERT MAP – Create a certificate filter
• RACDCERT ALTMAP – Change the certificate filter
• RACDCERT DELMAP – Delete a certificate filter
• RACDCERT LISTMAP – Display certificate filter information

32
 RACF Key Rings and certificates
• A key ring is a collection of certificates that identify a networking trust
relationship.
• A certificate must be placed in a key ring before it can be used by middleware
• applications
• Key Ring Syntax for applications: <user-id>/<ring-name>
• Types of Certificates in RACF:
• User – Directly Associated with one z/OS user ID (end entity)
• CERTAUTH – Trusted CA certificate used to verify the peer entity's certificate.
• SITE – Certificates associated with an off-platform server or other network
identity. SITE certificates bypass the normal certificate chain validation. Private keys can be
shared.
• Key Rings contain Certificate Usage – The usage assigned to a certificate when it is connected to
a key ring indicates its intended purpose.
• PERSONAL – Used to identify a local user or server application. Personal usage must be used
to get access to the private key.
• CERTAUTH – Used to verify the peer entity's certificate. Used to identify the local server's CA
certificate.
• SITE – Certificate associated with an off-platform server or other network identity. SITE
certificates bypass the normal certificate chain validation.

33
 Certificate Authority on z/OS:
PKI Services User Requests Certificate


• User Renews Certificate


Administrator
rejec
ts
Approves the
request


Certificate Expires
Or

Administrator or
User Revokes 
CA Generates and
Certificate distributes
certificate


Owner uses the
certificate
34
34
 Certificate Authority on z/OS:
PKI Services
• PKI Services provides full certificate life cycle management
• Request, create, renew, revoke certificates
• Provides certificate status:
• Certificate Revocation List (CRL)
• Online Certificate Status Protocol (OCSP)
• Generation and administration of certificates via customizable web
pages
• Support Simple Certificate Enrollment Protocol (SCEP) for
routers to request certificates automatically
• Automatic notifications or renewal of expiring certificates

35