3.9 Public Key Infrastructure Flashcards
• Policies, procedures, hardware, software, people
– Digital certificates: create, distribute, manage,
store, revoke
• This is a big, big, endeavor
– Lots of planning
• Also refers to the binding of public keys to people
or devices
– The certificate authority
– It’s all about trust
Public Key Infrastructure (PKI)
• Key generation – Create a key with the requested strength using the proper cipher • Certificate generation – Allocate a key to a user • Distribution – Make the key available to the user • Storage – Securely store and protect against unauthorized use • Revocation – Manage keys that have been compromised • Expiration – A certificate may only have a certain “shelf life”
The key management lifecycle
• A public key certificate
– Binds a public key with a digital signature
– And other details about the key holder
• A digital signature adds trust
– PKI uses Certificate Authority for additional trust
– Web of Trust adds other users for additional trust
• Certificate creation can be built into the OS
– Part of Windows Domain services
– 3rd-party Linux options
Digital certificates
• Built-in to your browser
– Any browser
• Purchase your web site certificate
– It will be trusted by everyone’s browser
• Create a key pair, send the public key to the CA
to be signed
– A certificate signing request (CSR)
• May provide different levels of trust and
additional features
– Add a new “tag” to your web site
Commercial certificate authorities
• You are your own CA
– Build it in-house
– Your devices must trust the internal CA
• Needed for medium-to-large organizations
– Many web servers and privacy requirements
• Implement as part of your overall computing strategy
– Windows Certificate Services, OpenCA
Private certificate authorities
• Single CA
– Everyone receives their certificates from one authority
• Hierarchical
– Single CA issues certs to intermediate CAs
– Distributes the certificate management load
– Easier to deal with the revocation of an intermediate
CA than the root CA
PKI trust relationships
• The entity requesting the certificate needs to be verified
– The RA identifies and authenticates the requester
• Approval or rejection
– The foundation of trust in this model
• Also responsible for revocations
– Administratively revoked or by request
• Manages renewals and re-key requests
– Maintains certificates for current cert holders
Registration authority (RA)
• Common Name (CN) – The FQDN (Fully Qualified – Domain Name) for the certificate • Subject alternative name – Additional host names for the cert – Common on web servers – professormesser.com and www.professormesser.com • Expiration – Limit exposure to compromise – 398 day browser limit (13 months)
Important certificate attributes
• Certificate Revocation List (CRL)
– Maintained by the Certificate Authority (CA)
• Many different reasons
– Changes all the time
• April 2014 - CVE-2014-0160
– Heartbleed
– OpenSSL flaw put the private key of affected
web servers at risk
– OpenSSL was patched, every web server
certificate was replaced
– Older certificates were moved to the CRL
Key revocation
• OCSP (Online Certificate Status Protocol)
– The browser can check certificate revocation
• Messages usually sent to an OCSP responder via HTTP
– Easy to support over Internet links
• Not all browsers/apps support OCSP
– Early Internet Explorer versions did not
support OCSP
– Some support OCSP, but don’t bother checking
Getting revocation details to the browser
• Domain validation certificate (DV)
– Owner of the certificate has some control over
a DNS domain
• Extended validation certificate (EV)
– Additional checks have verified the certificate
owner’s identity
– Browsers used to show a green name on the
address bar
– Promoting the use of SSL is now outdated
• Subject Alternative Name (SAN)
– Extension to an X.509 certificate
– Lists additional identification information
– Allows a certificate to support many
different domains
• Wildcard domain
– Certificates are based on the name of the server
– A wildcard domain will apply to all server names
in a domain
– *.professormesser.com
Web server SSL certificates
• Developers can provide a level of trust
– Applications can be signed by the developer
• The user’s operating system will examine
the signature
– Checks the developer signature
– Validates that the software has not been modified
• Is it from a trusted entity?
– The user will have the opportunity to stop the
application execution
Code signing certificate
• The public key certificate that identifies the root CA
(Certificate Authority)
– Everything starts with this certificate
• The root certificate issues other certificates
– Intermediate CA certificates
– Any other certificates
• This is a very important certificate
– Take all security precautions
– Access to the root certificate allows for the
creation of any trusted certificate
Root certificate
• Internal certificates don’t need to be signed by
a public CA
– Your company is the only one going to use it
– No need to purchase trust for devices that already
trust you
• Build your own CA
– Issue your own certificates signed by your own CA
• Install the CA certificate/trusted chain on all devices
– They’ll now trust any certificates signed by
your internal CA
– Works exactly like a certificate you purchased
Self-signed certificates
• You have to manage many devices
– Often devices that you’ll never physically see
• How can you truly authenticate a device?
– Put a certificate on the device that you signed
• Other business processes rely on the certificate
– Access to the remote access
– VPN from authorized devices
– Management software can validate the end device
Machine and computer certificates