#openssl req -new > eric.csr
#openssl x509 -req -in eric.csr -out eric.crt -signkey ca.key -CA ca.cert -CAkey ca.key -CAcreateserial -days 365
怎么我创建的crt不是个人证书,怎样才能创建个人证书.
ftp://www.linuxdoc.org/pub/linux/docs/HOWTO/SSL-Certificates-HOWTO
SSL Certificates HOWTO
Franck Martin
Revision History
Revision v0.3 2002-05-09 Revised by: FM
Adding x509v3 extension information - Correcting spelling
Revision v0.2 2001-12-06 Revised by: FM
Adding openssl.cnf file - Adding CRL info from Averroes- Correcting spelling
Revision v0.1 2001-11-18 Revised by: FM
Creation of the HOWTO
A first hand approach on how to manage a certificate authority (CA), and
issue or sign certificates to be used for secure web, secure e-mail, or
signing code and other usages.
-----------------------------------------------------------------------------
Table of Contents
1. Generalities
1.1. Introduction
1.2. What is SSL and what are Certificates?
1.3. What about S/Mime or other protocols?
2. Certificate Management
2.1. Installation
2.2. Create a Root Certification Authority Certificate.
2.3. Create a non root Certification Authority Certificate.
2.4. Install the CA root certificate as a Trusted Root Certificate
2.5. Certificate management
2.6. Securing Internet Protocols.
2.7. Securing E-mails.
2.8. Securing Code
-----------------------------------------------------------------------------
Chapter 1. Generalities
1.1. Introduction
Dear reader, like myself, you have intensively read the man pages of the
applications of the [http://www.openssl.org/] OpenSSL project, and like
myself, you couldn't figure out where to start, and how to work securely with
certificates. Here is the answer to most of your questions.
This HOWTO will also deal with non-linux applications: there is no use to
issue certificates if you can't use them... All applications won't be listed
here, but please, send me additional paragraphs and corrections. I can be
reached at the following address:[mailto: franck@sopac.org] franck@sopac.org.
-----------------------------------------------------------------------------
1.1.1. Disclaimer and Licence
This document is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.
In short, if the advises given here break the security of your e-commerce
application, then tough luck- it's never our fault. Sorry.
Copyright (c) 2001 by Franck Martin and others from the openssl-users mailing
list under GFDL (the [http://www.gnu.org/] GNU Free Documentation License).
Please freely copy and distribute (sell or give away) this document in any
format. It's requested that corrections and/or comments be forwarded to the
document maintainer. You may create a derivative work and distribute it
provided that you:
1. Send your derivative work (in the most suitable format such as sgml) to
the LDP (linux Documentation Project) or the like for posting on the
Internet. If not the LDP, then let the LDP know where it is available.
2. License the derivative work with this same license or use GPL. Include a
copyright notice and at least a pointer to the license used.
3. Give due credit to previous authors and major contributors. If you're
considering making a derived work other than a translation, it's
requested that you discuss your plans with the current maintainer.
It is also requested that if you publish this HOWTO in hardcopy that you send
the authors some samples for 'review purposes' :-). You may also want to send
something to cook my noodles ;-)
-----------------------------------------------------------------------------
1.1.2. Prior knowledge
As indicated in the introduction, this documents is an hand-on HOWTO, and it
is therefore required that you consult the man pages of the OpenSSL software.
You should as well read security books to learn how your security could be
compromised. Certificates are meant to increase the security of your
transactions, it is VERY important that you understand all the security
implications of your actions and what security OpenSSL does not provide.
-----------------------------------------------------------------------------
1.2. What is SSL and what are Certificates?
The Secure Socket Layer protocol was created by Netscape to ensure secure
transactions between web servers and browsers. The protocol uses a third
party, a Certificate Authority (CA), to identify one end or both end of the
transactions. This is in short how it works.
1. A browser requests a secure page (usually https://).
2. The web server sends its public key with its certificate.
3. The browser checks that the certificate was issued by a trusted party
(usually a trusted root CA), that the certificate is still valid and that
the certificate is related to the site contacted.
4. The browser then uses the public key, to encrypt a random symmetric
encryption key and sends it to the server with the encrypted URL required
as well as other encrypted http data.
5. The web server decrypts the symmetric encryption key using its private
key and uses the symmetric key to decrypt the URL and http data.
6. The web server sends back the requested html document and http data
encrypted with the symmetric key.
7. The browser decrypts the http data and html document using the symmetric
key and displays the information.
Several concepts have to be understood here.
-----------------------------------------------------------------------------
1.2.1. Private Key/Public Key:
The encryption using a private key/public key pair ensures that the data can
be encrypted by one key but can only be decrypted by the other key pair. This
is sometime hard to understand, but believe me it works. The keys are similar
in nature and can be used alternatively: what one key emcrypts, the other key
pair can decrypt. The key pair is based on prime numbers and their length in
terms of bits ensures the difficulty of being able to decrypt the message
without the key pairs. The trick in a key pair is to keep one key secret (the
private key) and to distribute the other key (the public key) to everybody.
Anybody can send you an encrypted message, that only you will be able to
decrypt. You are the only one to have the other key pair, right? In the
opposite , you can certify that a message is only coming from you, because
you have encrypted it with you private key, and only the associated public
key will decrypt it correctly. Beware, in this case the message is not
secured you have only signed it. Everybody has the public key, remember!
One of the problem left is to know the public key of your correspondent.
Usually you will ask him to send you a non confidential signed message that
will contains his publick key as well as a certificate.
-----------------------------------------------------------------------------
1.2.2. The Certificate:
How do you know that you are dealing with the right person or rather the
right web site. Well, someone has taken great length (if they are serious) to
ensure that the web site owners are who they claim to be. This someone, you
have to implicitly trust: you have his/her certificate loaded in your browser
(a root Certificate). A certificate, contains information about the owner of
the certificate, like e-mail address, owner's name, certificate usage,
duration of validity, resource location or Distinguished Name (DN) which
includes the Common Name (CN) (web site address or e-mail address depending
of the usage) and the certificate ID of the person who certifies (signs) this
information. It contains also the public key and finally a hash to ensure
that the certificate has not been tampered with. As you made the choice to
trust the person who signs this certificate, therefore you also trust this
certificate. This is a certificate trust tree or certificate path. Usually
your browser or application has already loaded the root certificate of well
known Certification Authorities (CA) or root CA Certificates. The CA
maintains a list of all signed certificates as well as a list of revoked
certificates. A certificate is insecure until it is signed, as only a signed
certificate cannot be modified. You can sign a certificate using itself, it
is called a self signed certificate. All root CA certificates are self
signed.
-----------------------------------------------------------------------------
1.2.3. The Symmetric key:
Well, Private Key/Public Key encryption algorithms are great, but they are
not usually practical. It is asymmetric because you need the other key pair
to decrypt. You can't use the same key to encrypt and decrypt. An algorithm
using the same key to decrypt and encrypt is deemed to have a symmetric key.
A symmetric algorithm is much faster in doing its job than an asymmetric
algorithm. But a symmetric key is potentially highly insecure. If the enemy
gets hold of the key then you have no more secret information. You must
therefore transmit the key to the other party without the enemy getting its
hands on it. As you know, nothing is secure on the Internet. The solution is
to encapsulate the symmetric key inside a message encrypted with an
asymmetric algorithm. You have never transmitted your private key to anybody,
then the message encrypted with the public key is secure (relatively secure,
nothing is certain except death and taxes). The symmetric key is also chosen
randomly, so that if the symmetric secret key is discovered then the next
transaction will be totally different.
-----------------------------------------------------------------------------
1.2.4. Encryption algorithm:
There are several encryption algorithms available, using symmetric or
asymmetric methods, with keys of various lengths. Usually, algorithms cannot
be patented, if Henri Poincare had patented his algorithms, then he would
have been able to sue Albert Einstein... So algorithms cannot be patented
except mainly in USA. OpenSSL is developed in a country where algorithms
cannot be patented and where encryption technology is not reserved to state
agencies like military and secret services. During the negotiation between
browser and web server, the applications will indicate to each other a list
of algorithms that can be understood ranked by order of preference. The
common preferred algorithm is then chosen. OpenSSL can be compiled with or
without certain algorithms, so that it can be used in many countries where
restrictions apply.
-----------------------------------------------------------------------------
1.2.5. The Hash:
A hash is a number given by a hash function from a message. This is a one way
function, it means that it is impossible to get the original message knowing
the hash. However the hash will drastically change even for the slightest
modification in the message. It is therefore extremely difficult to modify a
message while keeping its original hash. It is also called a message digest.
Hash functions are used in password mechanisms, in certifying that
applications are original (MD5 sum), and in general in ensuring that any
message has not been tampered with. It seems that the Internet Enginering
Task Force (IETF) prefers SHA1 over MD5 for a number of technical reasons (Cf
RFC2459 7.1.2 and 7.1.3).
-----------------------------------------------------------------------------
1.2.6. Signing:
Signing a message, means authentifying that you have yourself assured the
authenticity of the message (most of the time it means you are the author,
but not neccesarily). The message can be a text message, or someone else's
certificate. To sign a message, you create its hash, and then encrypt the
hash with your private key, you then add the encrypted hash and your signed
certificate with the message. The recipient will recreate the message hash,
decrypts the encrypted hash using your well known public key stored in your
signed certificate, check that both hash are equals and finally check the
certificate.
The other advantage of signing your messages is that you transmit your public
key and certificate automatically to all your recipients.
-----------------------------------------------------------------------------
1.2.7. PassPhrase:
??A passprase is like a password except it is longer??. In the early days
passwords on Unix system were limited to 8 characters, so the term passphrase
for longer passwords. Longer is the password harder it is to guess. Nowadays
Unix systems use MD5 hashes which have no limitation in length of the
password.
-----------------------------------------------------------------------------
1.3. What about S/Mime or other protocols?
If SSL was developed for web servers, it can be used to encrypt any protocol.
Any protocol can be encapsulated inside SSL. This is used in IMAPS, POPS,
SMTPS,... These secure protocols will use a different port than their
insecure version. SSL can also be used to encrypt any transaction: there is
no need to be in direct (live) contact with the recipient. S/Mime is such
protocol, it encapsulates an encrypted message inside a standard e-mail. The
message is encrypted using the public key of the recipient. If you are not
online with the recipient then you must know its public key. Either you get
it from its web site, from a repository, or you request the recipient to
e-mail you its public key and certificate (to ensure you are speaking to the
right recipient).
In a reverse order, the browser can send its own signed certificate to the
web server, as a mean of authentication. But everybody can get the browser
certificate on the CA web site. Yes, but the signed certificate has been sent
encrypted with the private key, that only the public key can decrypt.
-----------------------------------------------------------------------------
Chapter 2. Certificate Management
2.1. Installation
Nowadays, you do not have to worry too much about installing OpenSSL: most
distributions use package management applications. Refer to your distribution
documentation, or read the README and INSTALL file inside the OpenSSL
tarball. I want also to avoid to make this HOWTO, an installation HOWTO
rather than an HOWTO use certificates.
I describe here some standard installation options which are necessary to
know for the samples following. Your installation may differ.
The directory for all OpenSSL certificates is /var/ssl/. All commands and
paths in this document are issued from this directory, it is not mandatory
but it will help the examples.
OpenSSL by default looks for a configuration file in /usr/lib/ssl/openssl.cnf
so always add -config /etc/openssl.cnf to the commands openssl ca or openssl
req for instance. I use /etc/openssl.cnf so all my configuration files are
all in /etc.
Utilities and other libraries are located in /usr/lib/ssl.
-----------------------------------------------------------------------------
2.1.1. The CA.pl utility
Ensure that the utility CA.pl is in an accessible directory such as /usr/
sbin. CA.pl can be found inside /usr/lib/ssl directories. CA.pl is a utility
that hides the complexity of the openssl command. In all the examples, when I
use CA.pl, I will also put the openssl equivalent in brakets.
/usr/sbin/CA.pl needs to be modified to include -config /etc/openssl.cnf in
ca and req calls.
#$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"}
$SSLEAY_CONFIG="-config /etc/openssl.cnf";
-----------------------------------------------------------------------------
2.1.2. The openssl.cnf file
/etc/openssl.cnf must be configured accordingly to minimize input entry.
#---Begin---
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
RANDFILE = $ENV::HOME/.rnd
oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca' and 'req'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = /var/ssl # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem # The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = optional
localityName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
default_md = sha1
x509_extensions = v3_ca # The extentions to add to the self signed cert
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = FJ
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Fiji
localityName = Locality Name (eg, city)
localityName_default = Suva
0.organizationName = Organization Name (eg, company)
0.organizationName_default = SOPAC
# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = ITU
commonName = Common Name (eg, YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 40
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "Certificate issued by https://www.sopac.org/ssl/"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# Copy subject details
# issuerAltName=issuer:copy
# This is the base URL for all others URL addresses
# if not supplied
nsBaseUrl = https://www.sopac.org/ssl/
# This is the link where to download the latest Certificate
# Revocation List (CRL)
nsCaRevocationUrl = https://www.sopac.org/ssl/sopac-ca.crl
# This is the link where to revoke the certificate
nsRevocationUrl = https://www.sopac.org/ssl/revocation.html?
# This is the location where the certificate can be renewed
nsRenewalUrl = https://www.sopac.org/ssl/renewal.html?
# This is the link where the CA policy can be found
nsCaPolicyUrl = https://www.sopac.org/ssl/policy.html
# This is the link where we can get the issuer certificate
issuerAltName = URI:https://www.sopac.org/ssl/sopac.crt
# This is the link where to get the latest CRL
crlDistributionPoints = URI:https://www.sopac.org/ssl/sopac-ca.crl
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
# basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
# Some might want this also
# nsCertType = sslCA, emailCA
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy
# RAW DER hex encoding of an extension: beware experts only!
# 1.2.3.5=RAW:02:03
# You can even override a supported extension:
# basicConstraints= critical, RAW:30:03:01:01:FF
# This will be displayed in Netscape's comment listbox.
nsComment = "Certificate issued by https://www.sopac.org/ssl/"
# This is the base URL for all others URL addresses
# if not supplied
nsBaseUrl = https://www.sopac.org/ssl/
# This is the link where to download the latest Certificate
# Revocation List (CRL)
nsCaRevocationUrl = https://www.sopac.org/ssl/sopac-ca.crl
# This is the link where to revoke the certificate
nsRevocationUrl = https://www.sopac.org/ssl/revocation.html?
# This is the location where the certificate can be renewed
nsRenewalUrl = https://www.sopac.org/ssl/renewal.html?
# This is the link where the CA policy can be found
nsCaPolicyUrl = https://www.sopac.org/ssl/policy.html
# This is the link where we can get the issuer certificate
issuerAltName = URI:https://www.sopac.org/ssl/sopac.crt
# This is the link where to get the latest CRL
crlDistributionPoints = URI:https://www.sopac.org/ssl/sopac-ca.crl
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always
#----End----
A few comments on openssl.cnf.
* Variable names can use the suffixes _default for default value, _min for
the minimum number of characters required and _max for the maximum number
of characters required.
* The file is composed of [Sections] of variables.
dir:
Specifies the base directory.
default_ca:
Specifies which section contains the variables for a default certificate.
basicConstraints:
Defines the usage of the certificate, for instance with CA:TRUE, the
certificate is a root CA Certificate.
-----------------------------------------------------------------------------
2.1.3. Create the Certification Authority
To create a certification authority, use the command after correctly editing
openssl.cnf:
CA.pl -newca
-----------------------------------------------------------------------------
2.2. Create a Root Certification Authority Certificate.
CA.pl -newcert
(openssl req -config /etc/openssl.cnf -new -x509 -keyout newreq.pem -out newreq.pem -days 365)
creates a self signed certificate (for Certificate Authority). The resulting
file goes into newreq.pem. For the common Name (CN) use something like ??ACME
root Certificate??. This file needs to be split into 2 files cacert.pem and
private/cakey.pem. The part -RSA PRIVATE KEY- goes into private/cakey.pem
while the part -CERTIFICATE- goes into cacert.pem. Delete newreq.pem when
finished.
Now ensure that the file index.txt is empty and that the file serial contains
1.
You may want to increase the number of days so that your root certificate and
all the certificates signed by this root does not have to be changed when the
root certificate expires. I think professional companies work over 5 years to
10 years for their root certificates.
openssl req -config /etc/openssl.cnf-new -x509 -keyout private/cakey.pem -out cacert.pem -days 3650
This last command is better than ??CA.pl -newcert?? as it will place the
files in the required locations and create a root CA valid for 10 years.
Now ensure that this self signed root certificate is used only to sign other
certificates. The private key is highly sensible, never compromise it, by
removing the passphrase that protects it. Some people will place the private
key on a floppy and will load it only when signing other certificates. If you
computer gets hacked they can't physically get hold of the private key, if it
is on a floppy.
Now you have a root Certification Authority. Other people need to trust your
self-signed root CA Certificate, and therefore download it and register it on
their browser.
You will have to type the passphrase each time you want to sign another
certificate with it.
-----------------------------------------------------------------------------
2.3. Create a non root Certification Authority Certificate.
FIXME because I'm not sure about the procedure.
It is possible to use any signed certificate to sign any other certificate,
provided that the certificate is valid and has been issued with the signing
capability. So you can create a certificate request and a private key, make
the certificate been signed by a third party and install the signed
certificate and private key. The part -PRIVATE KEY- goes into private/
cakey.pem while the part -CERTIFICATE- goes into cacert.pem.
-----------------------------------------------------------------------------
2.4. Install the CA root certificate as a Trusted Root Certificate
First strip the certificate from all its text to keep only the -CERTIFICATE-
section
openssl x509 -in cacert.pem -out cacert.crt
Place this file on your web site as http://mysite.com/ssl/cacert.crt. Your
web server should have a mime entry for .crt files. Your certificate is ready
to be downloaded by any browser and saved.
It is important to publish the root CA Certificate on a web site as it is
unlikely that people will have it already loaded on their browser. Beware,
somebody could fake your web site and fake your root CA Certificate. If you
can have more than one way for users to get your certificate, it is unlikely
that a hacker will be able to corrupt everything.
-----------------------------------------------------------------------------
2.4.1. In Netscape
Download the certificate from the web server or from the file system using
Netscape. Netscape automatically recognises that it is a root certificate and
will propose you to add it in its store. Follow the wizard to install the
certifcate. At the end of the wizard you have to specify for which type of
application you trust this certifcate: web site security, e-mail signing, or
code signing.
-----------------------------------------------------------------------------
2.4.2. In Galeon
FIXME
-----------------------------------------------------------------------------
2.4.3. In Opera
FIXME
-----------------------------------------------------------------------------
2.4.4. In Internet Explorer
With your browser, point to the address of the certificate and save the file
on your disk. Double click on the file and the Certificate Installation
wizard will start. Because the certificate is self signed, Internet explorer
will automatically install it in the Trusted root Certificate Authority list.
From now on, Internet Explorer won't complain and any Certificate signed with
this root CA Certificate will be trusted too.
You can also open it from Internet explorer which will display the
certificate. Click on the button Install Certificate to launch the
Certificate Installation wizard.
-----------------------------------------------------------------------------
2.5. Certificate management
2.5.1. Generate and Sign a certificate request
CA.pl -newreq
(openssl req -config /etc/openssl.cnf -new -keyout newreq.pem -out newreq.pem -days 365)
creates a new private key and a certificate request and place it as
newreq.pem. Enter a Common Name (CN) the main usage of the certificate for
instance www.sopac.org if you want to secure the website www.sopac.org, or
enter franck@sopac.org if you want to use to secure the e-mails of
franck@sopac.org.
CA.pl -sign
(openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem -infiles newreq.pem)
will sign the request using the cacert.pem and commit the certificate as
newcert.pem. You will need to enter the passphrase of the cacert.pem (your CA
Certificate). The file newcerts/xx.pem will be created and index.txt and
serial will be updated.
You private key is in newreq.pem -PRIVATE KEY- and your certificate is in
newcert.pem -CERTIFICATE-
A copy of newcert.pem is placed in newcerts/ with an adequate entry in
index.txt so that a client can request this information via a web server to
ensure the authenticity of the certificate.
Beware of your newreq.pem file, because it contains a certificate request,
but also your private key. The -PRIVATE KEY- section is not required when you
sign it. So if you request someone else to sign your certificate request,
ensure that you have removed the -PRIVATE KEY- section from the file. If you
sign someone else certificate request, request from this person its
-CERTIFICATE REQUEST- section not its private key.
-----------------------------------------------------------------------------
2.5.2. Revoke a certificate
To revoke a certificate simply issue the command:
openssl -revoke newcert.pem
The database is updated and the certificate is marked as revoked. You now
need to generate the new revoked list of certificates:
openssl ca -gencrl -config /etc/openssl.cnf -out crl/sopac-ca.crl
This Certificate Revokation List (CRL) file should be made available on your
web site.
You may want to add the parameters crldays or crlhours and crlexts when you
revoke a certificate. The first two parameters indicate when the next CRL
will be updated and the last one will use the crl_exts section in openssl.cnf
to produce a CRL v2 instead of a CRL v1.
openssl ca -gencrl -config /etc/openssl.cnf -crldays 7 -crlexts crl_ext -out crl/sopac-ca.crl
-----------------------------------------------------------------------------
2.5.3. Renew a certificate
The user sends you its old certificate request or create a new one based on
its private key.
First you have to revoke the previous certificate and sign again the
certificate request.
To find the old certificate, look in the index.txt file for the Distinguished
Name (DN) corresponding to the request. Get the serial Number <xx>, and use
the file cert/<xx>.pem as certificate for the revocation procedure.
You may want to sign the request manually because you have to ensure that the
start date and end date of validity of the new certificate are correct.
openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem -infiles newreq.pem -startdate [now] -enddate [previous enddate+365days]
replace [now] and [previous enddate+365days] by the correct values.
-----------------------------------------------------------------------------
2.5.4. Display a certificate
You may have a certificate in its coded form, to read the details of the
certificate just issue the following command:
openssl x509 -in newcert.pem -noout -text
-----------------------------------------------------------------------------
2.5.5. The index.txt file
In the index.txt file you can find the various certificate managed by
OpenSSL. The entries are maked with R for Revoked, V for Valid and E for
expired.
-----------------------------------------------------------------------------
2.5.6. Build your web based Certificate Authority
There are a few requirements when you are a Certificate Authority (CA):
1. You must publish your root CA Certificate, so that it can be widely
installed in applications.
2. You must publish the revocation list.
3. You must display a certificate detail, provided its serial number
4. You must provide a form for users to submit certificate requests.
All these requirements can be done using a web server and some scripting.
FIXME: some code here for the web interface...
-----------------------------------------------------------------------------
2.6. Securing Internet Protocols.
2.6.1. Using a certificate with mod_ssl in apache
First never use your self-signed root CA Certificate with any application and
especially with apache as it requires you to remove the passphrase on your
private key.
First generate and sign a certificate request with the Common Name (CN) as
www.mysite.com. Remove any extra information to keep only the ---CERTIFCATE
--- part.
The key needs to be made insecure, so no password is required when reading
the private key. Take the newreq.pem files that contains your private key and
remove the passphrase from it.
openssl rsa -in newreq.pem -out wwwkeyunsecure.pem
Because the key (PRIVATE Key) is insecure, you must know what you are doing:
check file permissions, etc... If someone gets its hand on it, your site is
compromised (you have been warned). Now you can use the newcert and
cakeyunsecure.pem for apache.
Copy wwwkeyunsecure.pem and newcert.pem in the directory /etc/httpd/conf/ssl/
as wwwkeyunsecure.pem and wwwcert.crt respectively.
Edit /etc/httpd/conf/ssl/ssl.default-vhost.conf.
----
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A test
# certificate can be generated with `make certificate' under
# built time.
#SSLCertificateFile conf/ssl/ca.crt
SSLCertificateFile wwwcert.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file.
#SSLCertificateKeyFile conf/ssl/ca.key.unsecure
SSLCertificateKeyFile wwwkeyunsecure.pem
----
Stop and start httpd (/etc/rc.d/init.d/httpd stop) ensure that all processes
are dead (killall httpd) and start httpd (/etc/rc.d/init.d/httpd start)
-----------------------------------------------------------------------------
2.6.2. Using a certificate with IMAPS
FIXME
-----------------------------------------------------------------------------
2.6.3. Using a certificate with POPS
FIXME
-----------------------------------------------------------------------------
2.6.4. Using a certificate with Postfix
FIXME
-----------------------------------------------------------------------------
2.6.5. Using a certificate with Stunnel
FIXME
-----------------------------------------------------------------------------
2.6.6. Generate and Sign a key with Microsoft Key Manager
In Microsoft Key Manager, select the service you want to create a key for,
for instance IMAP (or WWW). Use the wizard to generate a new key. Ensure that
the distinguished name won't be identical to previous generated keys, for
Instance for the Common Name (CN) use imap.mycompany.com. The wizard will
place the request in the file C:NewKeyRq.txt. Key Manager shows a Key with a
strike to indicate the key is not signed.
Import this file in the OpenSSL /var/ssl directory, rename it to newreq.pem
and sign the request as usual.
CA.pl -sign
The file newcert.pem is not yet suitable for key manager as it contains some
text and the -CERTIFICATE- section. We have to remove the text, the easy way
is to do:
openssl x509 -in newcert.pem -out newcertx509.pem
Using a text editor is also suitable to delete everything outside the
-CERTIFICATE- section.
The newcertx509.pem file now contains only the -CERTIFICATE- section.
Export the file newcertx509.pem to the Computer running key Manager and while
selecting the key icon in the Key Manager application, right click and click
on Install the Key Certificate, select this file, enter the passphrase. The
key is now fully functional.
-----------------------------------------------------------------------------
2.7. Securing E-mails.
2.7.1. Generate and use an s/mime certificate
Simply generate and sign a certificate request but with the Common Name (CN)
being your e-mail address.
Now sign your message test.txt (output test.msg) using your certificate
newcert.pem and your key newreq.pem:
openssl smime -sign -in test.txt -text -out test.msg -signer newcert.pem -inkey newreq.pem
You can now transmit test.msg to anybody, you can use this procedure to make
signed advisories, or other signed documents to be published digitally.
-----------------------------------------------------------------------------
2.7.2. To use this certificate with MS Outlook
You need to import it in Outlook as a pkcs12 file. To generate the pkcs12
file from your newcert.pem and newreq.pem:
CA.pl -pkcs12 "Franck Martin"
(openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out newcert.p12 -name "Franck Martin")
Beware this certificate contains your public and private key and is only
secured by the passphrase. This is a file not to let into everybody's hand.
In MS Outlook go to Tools, Options and Security, Click on the import/export
button select to import the newcert.p12 file, enter the export password and
the Digital ID "Franck Martin" (That's my name so use your name in the above
examples). And Click on Ok.
Now click on the Settings button, MS Outlook should have selected the default
setting so just click on New. And finally click on Ok, except if you want to
change the default settings. You are ready to send signed e-mails. When you
send a signed e-mail the user at the other end will receive your public key,
and will therefore be able to send you encrypted e-mails.
As you have issued this certificate from a self-signed certificate (root CA
Certificate), the trust path won't be valid because the application does not
know the root CA Certificate. The root CA certificate has to be downloaded
and installed. Refer to the chapter "Install the CA root certificate as a
Trusted Root Certificate in Internet Explorer".
You can send your message as encrypted signed messages or clear text message.
The encryption is not really an encryption as the message contains everything
needed to decrypt the message, but it ensures that the recipient won't read
the message if he does not have an s/mime compliant reader.
-----------------------------------------------------------------------------
2.7.3. To use this certificate with MS Outlook Express
FIXME
-----------------------------------------------------------------------------
2.7.4. To use this certificate with Netscape Messenger
FIXME
-----------------------------------------------------------------------------
2.7.5. To use this certificate with Evolution
FIXME
-----------------------------------------------------------------------------
2.7.6. To use this certificate with Balsa
FIXME
-----------------------------------------------------------------------------
2.7.7. To use this certifcate with KMail
FIXME
-----------------------------------------------------------------------------
2.8. Securing Code
2.8.1. Micosoft Code
You can sign your programs and applet to certify that you are the author of
such code. It is important for your customes to trust that nobody has tried
to insert a virus or a backdoor inside your code. To authenticate your code
you need Microsoft Authenticode SDK. You can get it from the Microsoft web
site in the MSDN section.
Gernerate a certificate as usual but with a Common Name (CN) like ??ACME
Software Cert??. Have the certificate signed by the CA and convert it to a
pkcs12 format.
CA.pl -newcert
CA.pl -sign
CA.pl -pkcs12 "ACME Software Cert"
You get a file called newcert.p12 that you import in the Certificate store by
clicking on the file when in Windows.
You can now use this certificate for signing your code
signcode -cn "ACME Software cert" -tr 5 -tw 2 -n "My Application" -i http://www.acme.com/myapp/ -t http://timestamp.verisign.com/scripts/timstamp.dll myapp.exe
When you try to install and run your application a dialog will appears with
the title ??My Application?? and with a link pointed by the -i argument.
