Autorités de Certification et SSL

X.509

X.509 est une norme de cryptographie de l'Union internationale des télécommunications pour les infrastructures à clés publiques (PKI). X.509 établit entre autres un format standard de certificat électronique et un algorithme pour la validation de chemin de certification.

Il repose sur un système hiérarchique d'autorités de certification, à l'inverse des réseaux de confiance (comme PGP), où n'importe qui peut signer les certificats des autres.

Dans le système X.509, une autorité de certification attribue un certificat liant une clé publique à un nom distinctif (Distinguished Name), à une adresse électronique ou un enregistrement DNS.

Ce certificat place la signature d'une autorité de certification dans le dernier champ.

Concrètement cette signature est réalisée par :

* un condensat de tous les champs précédents du certificat,

* un chiffrement de ce condensat par la clé privée de l'autorité de certification.

N'importe qui possédant la clé publique de cette autorité de certification peut déchiffrer le condensat et le comparer au calcul de son propre condensat du certificat. Si les deux condensats sont identiques cela garantit que le certificat est intègre, il n'a pas été modifié. Le certificat de l'autorité de certification qui contient sa clé publique peut à son tour être signée par un autre certificat de plus haut niveau, formant ainsi une chaîne. Tout en haut de la chaîne on trouve les certificats les plus importants : les certificats racines.

Les certificats racines sont des clés publiques non signées, ou auto-signées, dans lesquelles repose la confiance. Les logiciels, comme les navigateurs Web ou les clients de messagerie détiennent des certificats racines de nombreuses autorités de certification commerciales ou gouvernementales. Quand un navigateur ouvre une connexion sécurisée (TLS/SSL) vers un site possédant une certificat émis par une autorité connue, il considère le site comme sûr dans la mesure où le chemin de certification est validé. Le passage en mode sécurisé est alors transparent.

Si le logiciel (navigateur ou autre) ne connaît pas l'autorité de certification (certificat généré et auto-signé par un particulier ou autorité de certification pas encore connue ou volontairement retirée de liste des autorités acceptées), le navigateur propose d'examiner de certificat, puis de l'accepter ou de le refuser selon la confiance qu'on lui accorde.

X509 peut être utilisé avec S/MIME, TLS/SSL, SET et IPsec .

Autorité de Certification

En cryptographie, l'autorité de certification (AC ou CA) a pour mission, après vérification de l'identité du demandeur du certificat par une autorité d'enregistrement, de signer, émettre et maintenir

* les certificats (CSR : Certificate Signing Request)

* les listes de révocation (CRL : Certificate Revocation List)

L'autorité de certification (AC) opère elle-même ou peut déléguer l'hébergement de la clé privée du certificat à un opérateur de certification (OC) ou autorité de dépôt.

Cette infrastructure de gestion des clés permet ainsi d'assurer que

* les données transmises n'ont pas été modifiées durant le transfert : intégrité par hachage des données

* les données proviennent bien de l'émetteur connu : utilisation de clés et répudiation

===== Créer une Autorité de Certification avec OpenSSL =====

==== Installer OpenSSL ====

aptitude install openssl

==== Creer une Autorité ====

OpenSSL est livré avec un ensemble de scripts capable de générer une CA. Se positionner dans le repertoire cible et executer la commande suivante pour créer une nouvelle CA :

/usr/lib/ssl/misc/CA.pl -newca

Cette opération va créer une clé privée, une clé publique et l'ensemble des élements de la CA.*

==== Creer les Certificats Clients - Apache ====

Your "client" creates a private key (.key) and a certificate request (.req):

/usr/lib/ssl/misc/CA.pl -newreq

You sign that request with your CA's key and create a certificate (.crt) that you send to the client:

/usr/lib/ssl/misc/CA.pl -sign

==== The 'makecrt' script ====

<code>

# Create SSL certificates

# Christoph Haas <email@christoph-haas.de>

DAYS=3650

OUTFILE=$1-apache.pem

if [ -z "$1" ]; then

echo "Usage: $0 [host.domain]"

exit 10

echo "Zertifikat für Host $1 wird erzeugt"

(

echo "My Country"

echo "My Region"

echo "My City"

echo "My Company"

echo "My Department"

echo $1

echo "webmaster@$1"

echo

) |

openssl req -new -nodes -keyout $1.key -out $1.req -days $DAYS

openssl ca -policy policy_anything -notext -days $DAYS -out $1.crt -infiles $1.req

chmod go= $1.crt $1.key $1.req

</code>

You will get three files:

mailserver.mydomain.com.key (the client's private key)

mailserver.mydomain.com.req (the client's certificate request)

mailserver.mydomain.com.crt (the client's signed certificate)

===== Liste de révocation de certificats =====

La liste de révocation de certificats (CRL, certificate revocation list) est la liste des identifiants des certificats qui ont été révoqués ou ne sont plus valables et qui ne sont plus dignes de confiance.

Un certificat peut devenir invalide pour de nombreuses raisons autres que l'expiration naturelle, telle que la perte ou la compromission de la clé privée associée au certificat ou le changement d'au moins un champ inclus dans le nom du titulaire/ détenteur du certificat.

C'est pourquoi la norme définit le format d'une liste indiquant les certificats devenus invalides pour une autorité de certification donnée. Cette liste est signée par l'autorité de certification pour en empêcher toute modification par une personne non autorisée. Elle comprend une date d'émission, une date de mise à jour (toutes 2 optionnelles) et la liste proprement dite sous la forme de paire (numéro de série du certificat révoqué ; motif éventuel de révocation). Le motif ne peut être présent que dans les CRL au format version 2.

Une limitation parfois gênante des CRL est le délai de propagation des informations de révocation. Pour le réduire, le protocole OCSP de validation de certificat a été développé. Défini dans la RFC 2560, il donne à peu près les mêmes informations que les CRL, mais potentiellement plus à jour.

La RFC 3280 liste les possibles états de révocation :

* « revoked », révocation définitive;

* « hold », révocation temporaire.

===== Commandes Utiles =====

==== Show all information about a certificate ====

openssl x509 -noout -text < crt

==== Calculate the MD5 fingerprint of a certificate ====

openssl x509 -noout -fingerprint < crt

==== Calculate the SHA1 fingerprint of a certificate: ====

openssl x509 -sha1 -noout -fingerprint < crt

==== Generation Clé SSL ====

openssl req -new -x509 -days 365 -nodes -out new-unit.pem -keyout new-unit.key

==== Concatener clé et certificat dans PEM ====

cat mailserver.mydomain.com.key mailserver.mydomain.crt > apache.pem

==== Generate a cool P12 File ====

openssl pkcs12 -export -in name-cert.pem -inkey private/name-key.pem -certfile cacert.pem -name "[friendly name]" -out name-cert.p12

==== Signer une requete ====

ca -policy policy_anything -notext -in clients.server.com.req -days 3650 -out clients.server.com.crt

Some tricks

==== Create a client certificate key ====

openssl genrsa -rand <Directory-Path>/<Random-Number-Filename> -out <Directory-Path>/<Client-Certificate-Key-Filename> <Key-Strength-in-Bits>

For example, to create a client certificate key client1.key by using the random number file /shared/exampleCA/.rand and the key size of 2048 bits, type the following command:

openssl genrsa -rand /shared/exampleCA/.rand -out /shared/exampleCA/client1.key 2048

==== Générer une clé et une demande de certificat ====

> openssl req -new -keyout userkey.pem -out usercert-req.pem

==== Create a client certificate signing request (CSR) ====

openssl req -new -out <Directory-Path>/<Client-CSR-Filename> -key <Directory-Path>/<Client-Certificate-Key-Filename>

For example, to create a client CSR client1.req by using the client certificate key client1.key, type the following command:

openssl req -new -out /shared/exampleCA/client1.req -key /shared/exampleCA/client1.key

==== Create and sign the client certificate ====

openssl x509 -req -in <Directory-Path>/<Client-Certificate-Request-Filename> -out <Directory-Path>/<Client-Certificate-Filename> -CAkey <Directory-Path>/<CA-Key-Filename> -CA <Directory-Path>/<CA-Cert-Filename> -days <Number-of-Days> -CAcreateserial -CAserial serial

For example, to create the client certificate client1.crt that is valid for 365 days by using the client certificate request client1.req, and sign it with the CA key clientCA.key and CA cert clientCA.crt, type the following command:

openssl x509 -req -in /shared/exampleCA/client1.req -out /shared/exampleCA/client1.crt -CAkey /shared/exampleCA/clientCA.key -CA /shared/exampleCA/clientCA.crt -days 365 -CAcreateserial -CAserial serial

===== Les différents fichiers d'identité =====

==== Certificate Signing Request - CSR ====

Some applications can generate these for submission to certificate-authorities. It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate, which itself can be in a couple of formats.

==== PEM ====

.pem Defined in RFC's 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. The name is from Privacy Enhanced Email, a failed method for secure email but the container format it used lives on.

==== KEY ====

.key This is a PEM formatted file containing just the private-key of a specific certificate. In Apache installs, this frequently resides in /etc/ssl/private. The rights on this directory and the certificates is very important, and some programs will refuse to load these certificates if they are set wrong.

==== Pkcs12====

.pkcs12 .pfx .p12 Originally defined by RSA in the Public-Key Cryptography Standards, the "12" variant was enhanced by Microsoft. This is a passworded container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Every time I get one I have to google to remember the openssl-fu required to break it into .key and .pem files.

===== Liens =====

* https://workaround.org/certificate-authority

Infrastructure de Clé Publique

Certificates are an important component of Transport Layer Security (TLS, sometimes called by its older name SSL, Secure Sockets Layer).

Contents of a typical digital certificate

See also: X.509 § Structure of a certificate

Serial Number: Used to uniquely identify the certificate.

Subject: The person, or entity identified.

Signature Algorithm: The algorithm used to create the signature.

Signature: The actual signature to verify that it came from the issuer.

Issuer: The entity that verified the information and issued the certificate.

Valid-From: The date the certificate is first valid from.

Valid-To: The expiration date.

Key-Usage: Purpose of the public key (e.g. encipherment, signature, certificate signing...).

Public Key: The public key.

Thumbprint Algorithm: The algorithm used to hash the public key certificate.

Thumbprint (also known as fingerprint): The hash itself, used as an abbreviated form of the public key certificate.

National Institute of Standards and Technology[edit]

The National Institute of Standards and Technology(NIST) Computer Security Division[2] provides guidance documents for Public Key Certificates:

SP 800-32 Introduction to Public Key Technology and the Federal PKI Infrastructure[3]

SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication[4]

Transport Layer Security

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as "SSL", are cryptographic protocols that provide communications security over a computer network.[1] Several versions of the protocols find widespread use in applications such as web browsing, email, Internet faxing, instant messaging, and voice-over-IP (VoIP). Major websites use TLS to secure all communications between their servers and web browsers.

The Transport Layer Security protocol aims primarily to provide privacy and data integrity between two communicating computer applications.[1]:3 When secured by TLS, connections between a client (e.g., a web browser) and a server (e.g., wikipedia.org) have one or more of the following properties:

* The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session (see TLS handshake protocol). The server and client negotiate the details of which encryption algorithm and cryptographic keys to use before the first byte of data is transmitted (see Algorithm below). The negotiation of a shared secret is both secure (the negotiated secret is unavailable to eavesdroppers and cannot be obtained, even by an attacker who places themselves in the middle of the connection) and reliable (no attacker can modify the communications during the negotiation without being detected).

* The identity of the communicating parties can be authenticated using public-key cryptography. This authentication can be made optional, but is generally required for at least one of the parties (typically the server).

* The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.[1]:3

The TLS protocol comprises two layers: the TLS record protocol and the TLS handshake protocol.

====== How to create a self-signed SSL Certificate ... ======

Overview

The Secure Socket Layer is used to encrypt the data stream between the web server and the web client (the browser). SSL makes use of what is known as asymmetric cryptography, commonly referred to as public key cryptography (PKI). With public key cryptography, two keys are created, one public, one private. Anything encrypted with either key can only be decrypted with its corresponding key. Thus if a message or data stream were encrypted with the server's private key, it can be decrypted only using its corresponding public key, ensuring that the data only could have come from the server.

If SSL utilizes public key cryptography to encrypt the data stream traveling over the Internet, why is a certificate necessary? The technical answer to that question is that a certificate is not really necessary - the data is secure and cannot easily be decrypted by a third party. However, certificates do serve a crucial role in the communication process. The certificate, signed by a trusted Certificate Authority (CA), ensures that the certificate holder is really who he claims to be. Without a trusted signed certificate, your data may be encrypted, however, the party you are communicating with may not be whom you think. Without certificates, impersonation attacks would be much more common.

Step 1: Generate a Private Key

The openssl toolkit is used to generate an RSA Private Key and CSR (Certificate Signing Request). It can also be used to generate self-signed certificates which can be used for testing purposes or internal usage. The first step is to create your RSA Private Key. This key is a 1024 bit RSA key which is encrypted using Triple-DES and stored in a PEM format so that it is readable as ASCII text.

<code>

openssl genrsa -des3 -out server.key 1024

Generating RSA private key, 1024 bit long modulus

.........................................................++++++

........++++++

e is 65537 (0x10001)

Enter PEM pass phrase:

Verifying password - Enter PEM pass phrase:

</code>

Step 2: Generate a CSR (Certificate Signing Request)

Once the private key is generated a Certificate Signing Request can be generated. The CSR is then used in one of two ways. Ideally, the CSR will be sent to a Certificate Authority, such as Thawte or Verisign who will verify the identity of the requestor and issue a signed certificate. The second option is to self-sign the CSR, which will be demonstrated in the next section.

During the generation of the CSR, you will be prompted for several pieces of information. These are the X.509 attributes of the certificate. One of the prompts will be for "Common Name (e.g., YOUR name)". It is important that this field be filled in with the fully qualified domain name of the server to be protected by SSL. If the website to be protected will be https://public.akadia.com, then enter public.akadia.com at this prompt. The command to generate the CSR is as follows:

<code>

openssl req -new -key server.key -out server.csr

Country Name (2 letter code) [GB]:CH

State or Province Name (full name) [Berkshire]:Bern

Locality Name (eg, city) [Newbury]:Oberdiessbach

Organization Name (eg, company) [My Company Ltd]:Akadia AG

Organizational Unit Name (eg, section) []:Information Technology

Common Name (eg, your name or your server's hostname) []:public.akadia.com

Email Address []:martin dot zahn at akadia dot ch

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

</code>

Step 3: Remove Passphrase from Key

One unfortunate side-effect of the pass-phrased private key is that Apache will ask for the pass-phrase each time the web server is started. Obviously this is not necessarily convenient as someone will not always be around to type in the pass-phrase, such as after a reboot or crash. mod_ssl includes the ability to use an external program in place of the built-in pass-phrase dialog, however, this is not necessarily the most secure option either. It is possible to remove the Triple-DES encryption from the key, thereby no longer needing to type in a pass-phrase. If the private key is no longer encrypted, it is critical that this file only be readable by the root user! If your system is ever compromised and a third party obtains your unencrypted private key, the corresponding certificate will need to be revoked. With that being said, use the following command to remove the pass-phrase from the key:

<code>

cp server.key server.key.org

openssl rsa -in server.key.org -out server.key

The newly created server.key file has no more passphrase in it.

-rw-r--r-- 1 root root 745 Jun 29 12:19 server.csr

-rw-r--r-- 1 root root 891 Jun 29 13:22 server.key

-rw-r--r-- 1 root root 963 Jun 29 13:22 server.key.org

</code>

Step 4: Generating a Self-Signed Certificate

At this point you will need to generate a self-signed certificate because you either don't plan on having your certificate signed by a CA, or you wish to test your new SSL implementation while the CA is signing your certificate. This temporary certificate will generate an error in the client browser to the effect that the signing certificate authority is unknown and not trusted.

To generate a temporary certificate which is good for 365 days, issue the following command:

<code>

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Signature ok

subject=/C=CH/ST=Bern/L=Oberdiessbach/O=Akadia AG/OU=Information

Technology/CN=public.akadia.com/Email=martin dot zahn at akadia dot ch

Getting Private key

</code>

Step 5: Installing the Private Key and Certificate

When Apache with mod_ssl is installed, it creates several directories in the Apache config directory. The location of this directory will differ depending on how Apache was compiled.

<code>

cp server.crt /usr/local/apache/conf/ssl.crt

cp server.key /usr/local/apache/conf/ssl.key

</code>

Step 6: Configuring SSL Enabled Virtual Hosts

<code>

SSLEngine on

SSLCertificateFile /usr/local/apache/conf/ssl.crt/server.crt

SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

CustomLog logs/ssl_request_log \

"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</code>

Step 7: Restart Apache and Test

<code>

/etc/init.d/httpd stop

/etc/init.d/httpd stop

https://public.akadia.com

</code>

====== OpenSSL ======

===== Introduction =====

The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation.

OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-style licence, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions.

Rechercher dans ce blog

MGZ DeFi Division