web-dev-qa-db-fra.com

Configurer l'authentification SSL mutuelle (bidirectionnelle)

Beaucoup de tutoriels, beaucoup de pages, beaucoup de questions et ils diffèrent dans la mise en œuvre de ce problème "Configurer l'authentification SSL mutuelle (bidirectionnelle)". Je dois le faire avec Linux, et je ne sais pas par où commencer ni quelles instructions suivre.

Ce que je dois faire, c'est:

  • J'ai un serveur et de nombreux clients, ils ne peuvent accéder au code sur le serveur que s'ils ont un certificat signé du serveur.
  • le serveur peut générer ces certificats et les désactiver. Le serveur principal serait l'autorité de certification. Cela signifie qu'il doit générer des certificats pour les autres, puis les signer.

J'avais pensé quoi faire

  1. générer un certificat CA
  2. générer des certificats pour d'autres utilisateurs.
  3. donner un certificat aux utilisateurs.
  4. signer des certificats.
  5. vérifier le certificat.
  6. régénérer le certificat pour l'utilisateur ou désactivé.
  7. l'utilisateur peut simplement signer à partir d'un seul appareil. (le certificat ne doit pas être copié)

Ai-je raté quelque chose? dois-je être un utilisateur root? y a-t-il un bash prêt pour cela? où puis-je le trouver.Pourquoi il y a plus d'un fichier openssl.cnf sur linux? où je devrais mettre le certificat CA toute information serait appréciée.

tlsauthenticationlinuxcertificate-authority
25
SafeY

Il y a un script pratique distribué avec openssl, CA.sh Pour faire la plupart de ces choses. Son emplacement est spécifique à la distribution. Dans Debian et ses dérivés, vous pouvez le localiser en utilisant:

# apt-file search CA.sh
openssl: /usr/lib/ssl/misc/CA.sh

Et RedHat et dérivés l'équivalent (approximatif) est:

# yum provides */CA
1:openssl-1.0.1e-4.fc18.x86_64 : Utilities from the general purpose cryptography library with TLS implementation
Repo        : @updates
Matched from:
Filename    : /etc/pki/tls/misc/CA

Il s'agit d'un script bash très simple qui facilite la création de la structure de répertoires nécessaire pour gérer une autorité de certification (cela est décrit dans la section [ CA_default ] De openssl.cnf). Je vous recommande de l'utiliser et de regarder le code pour savoir ce qu'il fait réellement.

# ./CA.sh -help
usage: ./CA.sh -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify

Ce script utilisera les valeurs par défaut fournies dans openssl.cnf, et/ou vous pouvez fournir un fichier de configuration comme argument au openssl $command En utilisant le commutateur -config Si vous n'utilisez pas CA.sh . L'emplacement du fichier openssl.cnf Est également spécifique à la distribution, et vous pouvez utiliser les mêmes commandes ci-dessus pour le trouver. Celui que vous voulez est celui fourni par le package openssl.

Vous souhaiterez probablement modifier les sections suivantes:

[ CA_default ]
default_days    = 365                   # how long to certify for
default_crl_days= 30                    # how long before next CRL

[ req ]
default_bits            = 2048

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = AU
countryName_min                 = 2
countryName_max                 = 2
stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Some-State
localityName                    = Locality Name (eg, city)
0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Internet Widgits Pty Ltd
#1.organizationName             = Second Organization Name (eg, company)
#1.organizationName_default     = World Wide Web Pty Ltd
organizationalUnitName          = Organizational Unit Name (eg, section)
#organizationalUnitName_default =
commonName                      = Common Name (e.g. server FQDN or YOUR name)
commonName_max                  = 64
emailAddress                    = Email Address
emailAddress_max                = 64
  • Générer l'AC

Une fois que vous avez modifié openssl.cnf Pour répondre à vos besoins, vous pouvez générer un certificat CA. Selon que vous avez besoin de cette autorité de certification signée par une autorité de certification tierce reconnue ou non, vous pouvez générer une autorité de certification auto-signée ou un CSR à soumettre pour signature.

./CA.sh -newca

Vous serez invité de manière interactive à poser quelques questions, les valeurs par défaut apparaîtront entre crochets. Vous reconnaîtrez ici les options que vous avez modifiées dans openssl.cnf.

  • Générer un certificat pour le serveur

Vous pouvez créer une demande de certificat pour le serveur en utilisant le même script:

./CA.sh -newreq

Encore une fois, vous serez invité à poser plusieurs questions, la plus importante étant le nom commun du certificat, qui doit correspondre au nom résolu DNS pour l'IP du serveur (ou vous pouvez utiliser d'autres moyens, comme /etc/hosts , non recommandé, difficile à maintenir et à mettre à l'échelle)

Vous obtiendrez une demande de signature de certificat (CSR pour faire court). Celui-ci sera signé par l'autorité de certification (CA) que vous avez créée auparavant.

./CA.sh -sign

  • Générer des certificats pour les clients

Répétez les étapes de création d'un CSR et de le faire signer par l'autorité de certification. Ce faisant, prêtez une attention particulière à la façon dont vous remplissez les champs Nom commun, Organisation et Unité organisationnelle, car ceux-ci seront nécessaires par la suite pour configurer le serveur.

Une bonne façon de distribuer les certificats clients aux côtés de leurs clés privées respectives et le certificat CA utilise des bundles p12:

openssl pkcs12 -export -in Certificates/client.pem -inkey client.key -certfile CA.pem -out clientcert.p12

  • Configurer le serveur

Supposons que le serveur auquel vous faites référence est un serveur Web Apache. Une fois que vous avez le certificat de serveur, vous configurez le VHOST approprié pour servir le contenu qui sera protégé par l'authentification SSL mutuelle. Un exemple pourrait être ce phpmyadmin hôtes virtuels. Cela fonctionne sur un serveur Apache 2.4, donc ne l'utilisez pas tel quel et examinez-le attentivement et testez-le pour l'adapter à vos besoins.

Listen                   443 https

<VirtualHost 120.120.120.120:443>
  DocumentRoot           "/srv/www/html"
  ServerAdmin            [email protected]
  SSLCACertificateFile   /etc/pki/CA/cacert.pem
  SSLCertificateFile     /etc/pki/tls/private/phpmyadmin.company.com/newcert.pem
  SSLCertificateKeyFile  /etc/pki/tls/private/phpmyadmin.company.com/newkey.pem
  SSLCARevocationCheck   chain
  SSLCARevocationFile    /etc/pki/CA/crl/crl.pem
  SSLEngine              on
  SSLStrictSNIVHostCheck on
  SSLVerifyClient        require
  SSLVerifyDepth         5
  ServerName             phpmyadmin.company.com
  RewriteEngine          on
  RewriteCond            %{REMOTE_ADDR} !^127\.0\.0\.1$
  RewriteCond            %{HTTPS} !=on
  RewriteRule            . - [F]
  Alias                  /console /usr/share/phpMyAdmin
  ErrorLog               "|/usr/sbin/rotatelogs -L /var/log/httpd/phpmyadmin/error.log -f /var/log/httpd/phpmyadmin/error.log.%Y%m%d 86400"
  CustomLog              "|/usr/sbin/rotatelogs -L /var/log/httpd/phpmyadmin/access.log -f /var/log/httpd/phpmyadmin/access.log.%Y%m%d 86400" logstash_json
  <Directory /usr/share/phpMyAdmin/>
    Require              ssl
    Require              ssl-verify-client
    SSLRequireSSL
    SSLOptions           +FakeBasicAuth +StrictRequire
    SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 256
    SSLRequire           %{SSL_CLIENT_S_DN_O} eq "Awesome Company" \
                     and %{SSL_CLIENT_S_DN_OU} eq "Development" \
                     and %{SSL_CLIENT_S_DN_CN} in {"John Doe", "Jane Doe"}
    SSLRenegBufferSize   131072
  </Directory>
</VirtualHost>

Vous pouvez utiliser autant de contrôles d'accès par répertoire que vous le souhaitez, l'important étant que les certificats clients affichés doivent respecter les restrictions imposées par les directives SSLRequire, c'est-à-dire qu'ils doivent correspondre à l'organisation, à l'unité organisationnelle et Conditions de nom commun (ou d'autres champs du certificat comme bon vous semble). Ces champs sont extraits des certificats clients.

  • Générer une liste de révocation de certificats

Pour pouvoir révoquer l'accès à un certificat client, vous devez générer une liste de révocation de certificats. La commande pour le faire (à condition que vous soyez en haut de la structure du répertoire CA):

openssl ca -config /path/to/openssl.cnf -gencrl -out crl/crl.pem

Ensuite, vous révoquez les certificats client selon les besoins en utilisant:

openssl ca -config /path/to/openssl.cnf -revoke clientcert.pem

Références:

OpenSSL documentation en ligne et Apache documentation en ligne.

18
dawud