SSL Cert Request - SDSU IT Security Office

Download Report

Transcript SSL Cert Request - SDSU IT Security Office

TLS/SSL Review
Transport Layer Security
A 30-second history
Secure Sockets Layer was developed by Netscape in 1994 as a
protocol which permitted persistent and secure transactions. In
1997 an Open Source version of Netscape’s patented version
was created, which is now OpenSSL. In 1999 the existing
protocol was extended by a version now known as Transport
Layer Security (TLS). By convention, the term "SSL" is used
even when technically the TLS protocol is being used.
TLS: Server Certificate
• Authentication
– Server and/or client identity is verified via certificate.
• Privacy
– Data is encrypted with block cipher
– Cipher key is exchanged via public key
TLS: Server Certificate Verification
• The client browser recognizes the Certificate Authority
and thus verifies the authenticity of the connection.
Failed Verification
If there is a conflict between the name on the certificate
and the name of the server, the browser pops up a
“Domain Name Mismatch” notice, allowing the user to
decide whether to continue.
Cert Request: CSR
• CSR: Certificate Signing Request
• It contains:
o Information about the organization
(organization name, country, etc...)
o Web Server's public key
o A unique mathematical match to server's
private key .
Cert Request: CSR
• Let’s Create one
(cont.)
Cert Request
•
•
•
•
•
•
Go to http://security.sdsu.edu/services/ssl/
Common Name: ricardoserver.sdsu.edu
Server software:
Certificate Term: 1,2, or 3 years
CSR: 2048-bit CSR
Pass-phrase: (Don’t use)
Cert Request
Cert Request: Type
Certificate Type
Description & Purpose
Single domain (Incommon SSL
Certificate)
SSL certificate protects a single domain e.g.
www.sdsu.edu. These are the "traditional" SSL
certificates that have been in use since the
advent of the SSL protocol.
Multiple domain (Incommon Multi-domain
SSL certificate)
A multiple domain certificate allows you protect
multiple host names with a single SSL
certificate. These are also known as SAN
(Subject Alternative Name) certificates. Up to
100 domain names can be included in a multidomain certificate.
These certificates are often used on a single
servers hosting many web sites to eliminate the
need to use unique IP addresses for each web
site e.g. www.sdsu.edu and www.ba.sdsu.edu.
Cert Request: Type
Certificate Type
(cont.)
Description & Purpose
Wildcard (Incommon wildcard SSL
certificate)
A wildcard certificate protects a domain and
unlimited subdomains of that domain e.g.
(not used for sdsu.edu)
UCC Exchange (Incommon Unified
Communications Certificate)
A unified communications certificate allows
you to protect multiple host names with a single
SSL certificate. Specifically designed for
Microsoft Exchange and Microsoft Office
Communications Server. Newer versions of
Microsoft products will work with multi-domain
certificates.
Cert Request: Type
Certificate Type
(cont.)
Description & Purpose
Extended validation single domain
(Comodo EV SGC SSL certificate)
An Extended Validation certificate protects a
single domain e.g. my.sdsu.edu. However, the
certificate is issued according to a specific set
of identity verification criteria. Certificates
issued by a CA under the EV guidelines are not
structurally different from other certificates but
are designated with a CA-specific policy
identifier so that EV-aware software (browsers)
can recognize them and display the "green
bar".
Extended validation multiple domain
(Comodo EV multi-domain SSL
certificate)
See above, except this certificate can protect
multiple domains.
Cert Request: Email
Hello,
You have successfully enrolled for an InCommon SSL certificate.
You now need to complete the following steps:
* Click the following link to download your SSL certificate (generally try to use a version that includes intermediates &
root or your certificate may be rejected by some older clients)
Format(s) most suitable for your server software:
as X509 Certificate only, Base64 encoded: https://certmanager.com/customer/InCommon/ssl?action=download&sslId=xxxx&format=x509CO
as X509 Intermediates/root only, Base64 encoded: https://certmanager.com/customer/InCommon/ssl?action=download&sslId=xxxx&format=x509IO
as X509 Intermediates/root only Reverse, Base64 encoded: https://certmanager.com/customer/InCommon/ssl?action=download&sslId=xxxxx&format=x509IOR
Other available formats:
as PKCS#7 Base64 encoded: https://certmanager.com/customer/InCommon/ssl?action=download&sslId=xxxxxx&format=base64
as PKCS#7 Bin encoded: https://certmanager.com/customer/InCommon/ssl?action=download&sslId=xxxxx&format=bin
as X509, Base64 encoded: https://certmanager.com/customer/InCommon/ssl?action=download&sslId=xxxxxx&format=x509
Cert Request: Email
Which File to download?
•
X509 Certificate only, Base64 encoded
This file contains only your domain/entity certificate and is commonly used with Apache-based systems (Apache
Directive: SSLCertificateFile), Tomcat and Oracle Wallet Manager.
•
X509 Intermediates/root only, Base64 encoded
This file includes only the Root and Intermediate CA certificates (in order) for your domain/entity certificate.
•
X509 Intermediates/root only (Reverse), Base64 encoded
This file contains only the Intermediate(s) and Root CA certificates (in reverse order) and is commonly used with
Apache-based systems (Apache2 Directive: SSLCertificateChainfile). This file is also known as a 'CA Bundle' or
'Certificate Chain File'.
Other available formats:
•
•
PKCS#7 Base64 encoded
PKCS#7 Bin encoded
PKCS#7 is commonly used with IIS 5.x and later.
This file contains the: Root, Intermediate(s) and your certificate; all rolled into a single file.
•
X509, Base64 encoded
This file typically includes (in order): Root, Intermediate(s) and your certificate.
Cert Request: Email
PKCS#7 vs. X509?
•
•
•
•
PKCS#7 is a cryptography standard published by RSA Security in 1993 that deals
with data that has cryptography applied to it. Its a standard for how to package data
securely. PKCS#7 references the X.509 standard, as the source for certificate
formatting.
X.509 is a wide ranging security standards document published in 1998 which
includes amongst other things, certificate file formats.
X.509 specifies that certificates should be encoded using the Distinguished Encoding
Rules of the ASN.1 (documented in the X.208 and now X.608) standard, first
published in 1984.
So, DER says how to encode some strings and numeric source data into a binary
format, X.509 says which data needs to go into a digital certificate, and PKCS#7 says
how that certificate should be used, to digitally sign a message.
SSL Cert: Install
• Add to httpd.conf
– SSLEngine on
– SSLCertificateKeyFile /etc/ssl/ssl.key/server.key
– SSLCertificateFile /etc/ssl/ssl.crt/yourDomainName.crt
– SSLCertificateChainFile /etc/ssl/ssl.crt/yourDomainName.cabundle
• Restart apache
SSL Cert Expr. Monitoring
•
Nagios
•
Bash Script : http://prefetch.net/code/ssl-cert-check
SSL Cert
Thank you
Questions:
Email me at [email protected]