IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Installer un serveur dédié sous Ubuntu Serveur

Date de publication : 09 décembre 2011.


IV. Les connexions sécurisés avec SSL
IV-A. Certificat SSL auto-signé
IV-B. Certificat SSL traditionnel
IV-C. Mise en place de SSL pour Apache
IV-C-1. default-ssl et certificat auto-signé
IV-C-2. default-ssl et certificat traditionnel


IV. Les connexions sécurisés avec SSL

La mise en place de certificat SSL nous permettra de sécuriser l'échange de donnée qu'il s'agisse de site web, de ftp ou d'éventuels autres services.
Nous disposons de deux possibilités concernant l'obtention de ce certificat

  • Certificat SSL auto-signé : il a l'inconvénient d'afficher un message assez alarmiste sur les navigateurs web actuels mais peut être très pratique pour des échanges de données internes
  • Certificat SSL traditionnel : souvent payant (mais pas toujours), c'est celui le plus couramment utilisé et le plus rassurant pour les utilisateurs. Il sert essentiellement en front-office
En fonction de vos besoins, vous pouvez opter pour l'un, pour l'autre ou pour les deux. Bien que la génération de certificat SSL auto-signé est expliqué par la suite, nous vous recommandons de vous orienté vers un certificat SSL traditionnel. Nous vous proposerons également un des nombreux sites nous permettant l'obtention de ce certificat gratuitement.


IV-A. Certificat SSL auto-signé

la génération d'un certificat SSL auto-signé nécessite openssl. Ce dernier est normalement déjà installé, cependant si ce n'est pas le cas, vous avez la possibilité de l'installer via aptitude ( apt-get install openssl ).

La commande suivante va vous permettre de générer votre certificat :

sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -out /etc/ssl/server.crt -keyout /etc/ssl/server.key
  • -days 365 indique la durée de validité (en jours) de votre certificat
  • -newkey rsa:1024 chiffrement RSA de 1024 bits - il est recommandé de ne pas dépassé 1024 bits pour des raisons de compatibilités
  • -out /etc/ssl/server.crtemplacement de sortie et nom du certificat
  • -keyout /etc/ssl/server.key emplacement de sortie et nom de la clé
Suite à cette commande, nous devons renseigner quelques champs

  • Country Name (2 letter code) [GB]: FR à remplir en fonction de votre pays
  • State or Province Name (full name) [Some-State]: FRANCE correspond également à votre pays
  • Locality Name (eg, city) []: PARIS votre ville
  • Organization Name (eg, company; recommended) []: monsite.fr Nom de la société ou, à défaut, nom de domaine
  • Organizational Unit Name (eg, section) []: monsite.fr Nom du département de la société ou, à défaut, nom de domaine
  • Common Name (eg, YOUR name) []: *.monsite.fr Nom de domain à sécuriser, doit être correctement rempli (préfixé de *. les sous-domaines pourront être sécurisés).
  • Email Address []: postmaster@monsite.fr Adresse e-mail de l'administrateur
Vous constaterez que nous disposons maintenant des fichiers server.crt et server.key situé dans notre répertoire /etc/ssl/
Pour de protéger notre clé, nous allons lui changer ses droits afin qu'il ne puisse être lu par d'autres utilisateurs :

sudo chmod 440 /etc/ssl/server.key
Nos certificat et clé sont maintenant prêt à l'emploi, il ne nous restera plus qu'à les utiliser en fonction de nos besoin.


IV-B. Certificat SSL traditionnel

Le gros avantage de ce certificat est qu'il est signé par une autorité compétente. Ne générant pas d'exception au niveau des navigateurs web, il dispose donc du caractère rassurant souhaité par les utilisateurs.

Bien souvent, il est payant, cependant il existe quelques sites nous permettant d'en obtenir un gratuitement (par exemple StartSSL).
Veillez à bien fournir les informations demandées pour la création du couple clé/certificat SSL. En effet, de fausses informations peuvent entraîner quelques disfonctionnements.

Vous pouvez enregistrer vos fichiers server.key et server.crt dans le répertoire /etc/ssl et changer les droits de server.key afin d'empêcher tout accès par d'autres utilisateurs :

sudo chmod 440 /etc/ssl/server.key
Selon votre fournisseur SSL, il peut être nécessaire de télécharger quelques fichiers supplémentaires.
Par exemple, si vous avez choisi StartSSL, vous devez copier ces fichiers dans /etc/ssl : ca.pem et sub.class1.server.ca.pem
ou les télécharger selon la méthode suivante :

cd /etc/ssl
sudo wget http://www.startssl.com/certs/ca.pem
sudo wget http://www.startssl.com/certs/sub.class1.server.ca.pem

IV-C. Mise en place de SSL pour Apache

Tout comme nous avons définit le profil default d'Apache concernant les connexions standards, nous allons maintenant définir default-ssl en vu d'avoir un profil type concernant les connexions sécurisées.

Mais avant cela, activons le module ssl d'Apache :

sudo a2enmod ssl
Puis éditons le fichier default-ssl :

sudo nano /etc/apache2/sites-available/default-ssl
Et modifions le en fonction du type de certificat SSL choisi.


IV-C-1. default-ssl et certificat auto-signé

Nous devons ici modifier les lignes SSLCertificateFile et SSLCertificateKeyFile afin de fournir les clé et certificat SSL à Apache. Elles devraient ressembler maintenant à cela :

        SSLCertificateFile    /etc/ssl/server.crt
        SSLCertificateKeyFile /etc/ssl/server.key
vous pouvez sinon remplacer tout le contenu par ce qui suit :


<IfModule mod_ssl.c>
<VirtualHost _default_:443>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/ssl_access.log combined

        Alias /doc/ "/usr/share/doc/"
        <Directory "/usr/share/doc/">
                Options Indexes MultiViews FollowSymLinks
                AllowOverride None
                Order deny,allow
                Deny from all
                Allow from 127.0.0.0/255.0.0.0 ::1/128
        </Directory>

        #   SSL Engine Switch:
        #   Enable/Disable SSL for this virtual host.
        SSLEngine on

        #   A self-signed (snakeoil) certificate can be created by installing
        #   the ssl-cert package. See
        #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
        #   If both key and certificate are stored in the same file, only the
        #   SSLCertificateFile directive is needed.
        SSLCertificateFile    /etc/ssl/server.crt
        SSLCertificateKeyFile /etc/ssl/server.key

        #   Server Certificate Chain:
        #   Point SSLCertificateChainFile at a file containing the
        #   concatenation of PEM encoded CA certificates which form the
        #   certificate chain for the server certificate. Alternatively
        #   the referenced file can be the same as SSLCertificateFile
        #   when the CA certificates are directly appended to the server
        #   certificate for convinience.
        #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

        #   Certificate Authority (CA):
        #   Set the CA certificate verification path where to find CA
        #   certificates for client authentication or alternatively one
        #   huge file containing all of them (file must be PEM encoded)
        #   Note: Inside SSLCACertificatePath you need hash symlinks
        #         to point to the certificate files. Use the provided
        #         Makefile to update the hash symlinks after changes.
        #SSLCACertificatePath /etc/ssl/certs/
        #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt

        #   Certificate Revocation Lists (CRL):
        #   Set the CA revocation path where to find CA CRLs for client
        #   authentication or alternatively one huge file containing all
        #   of them (file must be PEM encoded)
        #   Note: Inside SSLCARevocationPath you need hash symlinks
        #         to point to the certificate files. Use the provided
        #         Makefile to update the hash symlinks after changes.
        #SSLCARevocationPath /etc/apache2/ssl.crl/
        #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

        #   Client Authentication (Type):
        #   Client certificate verification type and depth.  Types are
        #   none, optional, require and optional_no_ca.  Depth is a
        #   number which specifies how deeply to verify the certificate
        #   issuer chain before deciding the certificate is not valid.
        #SSLVerifyClient require
        #SSLVerifyDepth  10

        #   Access Control:
        #   With SSLRequire you can do per-directory access control based
        #   on arbitrary complex boolean expressions containing server
        #   variable checks and other lookup directives.  The syntax is a
        #   mixture between C and Perl.  See the mod_ssl documentation
        #   for more details.
        #<Location />
        #SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
        #            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
        #            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
        #            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
        #            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
        #           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
        #</Location>

        #   SSL Engine Options:
        #   Set various options for the SSL engine.
        #   o FakeBasicAuth:
        #     Translate the client X.509 into a Basic Authorisation.  This means that
        #     the standard Auth/DBMAuth methods can be used for access control.  The
        #     user name is the `one line' version of the client's X.509 certificate.
        #     Note that no password is obtained from the user. Every entry in the user
        #     file needs this password: `xxj31ZMTZzkVA'.
        #   o ExportCertData:
        #     This exports two additional environment variables: SSL_CLIENT_CERT and
        #     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
        #     server (always existing) and the client (only existing when client
        #     authentication is used). This can be used to import the certificates
        #     into CGI scripts.
        #   o StdEnvVars:
        #     This exports the standard SSL/TLS related `SSL_*' environment variables.
        #     Per default this exportation is switched off for performance reasons,
        #     because the extraction step is an expensive operation and is usually
        #     useless for serving static content. So one usually enables the
        #     exportation for CGI and SSI requests only.
        #   o StrictRequire:
        #     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
        #     under a "Satisfy any" situation, i.e. when it applies access is denied
        #     and no other module can change it.
        #   o OptRenegotiate:
        #     This enables optimized SSL connection renegotiation handling when SSL
        #     directives are used in per-directory context.
        #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

        #   SSL Protocol Adjustments:
        #   The safe and default but still SSL/TLS standard compliant shutdown
        #   approach is that mod_ssl sends the close notify alert but doesn't wait for
        #   the close notify alert from client. When you need a different shutdown
        #   approach you can use one of the following variables:
        #   o ssl-unclean-shutdown:
        #     This forces an unclean shutdown when the connection is closed, i.e. no
        #     SSL close notify alert is send or allowed to received.  This violates
        #     the SSL/TLS standard but is needed for some brain-dead browsers. Use
        #     this when you receive I/O errors because of the standard approach where
        #     mod_ssl sends the close notify alert.
        #   o ssl-accurate-shutdown:
        #     This forces an accurate shutdown when the connection is closed, i.e. a
        #     SSL close notify alert is send and mod_ssl waits for the close notify
        #     alert of the client. This is 100% SSL/TLS standard compliant, but in
        #     practice often causes hanging connections with brain-dead browsers. Use
        #     this only for browsers where you know that their SSL implementation
        #     works correctly.
        #   Notice: Most problems of broken clients are also related to the HTTP
        #   keep-alive facility, so you usually additionally want to disable
        #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
        #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
        #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
        #   "force-response-1.0" for this.
        BrowserMatch "MSIE [2-6]" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        # MSIE 7 and newer should be able to use keepalive
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>
</IfModule>
La configuration des connexions SSL auto-signée est maintenant terminée. Nous verrons comment l'utiliser au travers de différents services (Web, FTP, ....)


IV-C-2. default-ssl et certificat traditionnel

Comme nous l'avons vu, le certificat SSL traditionnel peut comporter quelques fichiers supplémentaires (ca.pem et sub.class1.server.ca.pem dans notre exemple).
Ces fichiers vont permettre à notre connexion SSL de trouver l'autorité correspondante à son certificat.

Nous devons donc modifier les propriétés suivantes SSLCertificateFile et SSLCertificateKeyFile mais également définir SSLCertificateChainFile et SSLCACertificateFile et configurer quelques options

        SSLCertificateFile			/etc/ssl/server.crt
        SSLCertificateKeyFile		/etc/ssl/server.key
        SSLCertificateChainFile		/etc/ssl/sub.class1.server.ca.pem
        SSLCACertificateFile		/etc/ssl/ca.pem

        SSLProtocol all -SSLv2
        SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM		    
vous pouvez sinon remplacer tout le contenu par ce qui suit :


<IfModule mod_ssl.c>
<VirtualHost _default_:443>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/ssl_access.log combined

        Alias /doc/ "/usr/share/doc/"
        <Directory "/usr/share/doc/">
                Options Indexes MultiViews FollowSymLinks
                AllowOverride None
                Order deny,allow
                Deny from all
                Allow from 127.0.0.0/255.0.0.0 ::1/128
        </Directory>

        #   SSL Engine Switch:
        #   Enable/Disable SSL for this virtual host.
        SSLEngine on

        #   A self-signed (snakeoil) certificate can be created by installing
        #   the ssl-cert package. See
        #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
        #   If both key and certificate are stored in the same file, only the
        #   SSLCertificateFile directive is needed.
        SSLCertificateFile    /etc/ssl/server.crt
        SSLCertificateKeyFile /etc/ssl/server.key

        #   Server Certificate Chain:
        #   Point SSLCertificateChainFile at a file containing the
        #   concatenation of PEM encoded CA certificates which form the
        #   certificate chain for the server certificate. Alternatively
        #   the referenced file can be the same as SSLCertificateFile
        #   when the CA certificates are directly appended to the server
        #   certificate for convinience.
        SSLCertificateChainFile /etc/ssl/sub.class1.server.ca.pem

        #   Certificate Authority (CA):
        #   Set the CA certificate verification path where to find CA
        #   certificates for client authentication or alternatively one
        #   huge file containing all of them (file must be PEM encoded)
        #   Note: Inside SSLCACertificatePath you need hash symlinks
        #         to point to the certificate files. Use the provided
        #         Makefile to update the hash symlinks after changes.
        #SSLCACertificatePath /etc/ssl/certs/
        SSLCACertificateFile /etc/ssl/ca.pem

        #   Certificate Revocation Lists (CRL):
        #   Set the CA revocation path where to find CA CRLs for client
        #   authentication or alternatively one huge file containing all
        #   of them (file must be PEM encoded)
        #   Note: Inside SSLCARevocationPath you need hash symlinks
        #         to point to the certificate files. Use the provided
        #         Makefile to update the hash symlinks after changes.
        #SSLCARevocationPath /etc/apache2/ssl.crl/
        #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

        #   Client Authentication (Type):
        #   Client certificate verification type and depth.  Types are
        #   none, optional, require and optional_no_ca.  Depth is a
        #   number which specifies how deeply to verify the certificate
        #   issuer chain before deciding the certificate is not valid.
        #SSLVerifyClient require
        #SSLVerifyDepth  10

        #   Access Control:
        #   With SSLRequire you can do per-directory access control based
        #   on arbitrary complex boolean expressions containing server
        #   variable checks and other lookup directives.  The syntax is a
        #   mixture between C and Perl.  See the mod_ssl documentation
        #   for more details.
        #<Location />
        #SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
        #            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
        #            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
        #            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
        #            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
        #           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
        #</Location>

        #   SSL Engine Options:
        #   Set various options for the SSL engine.
        #   o FakeBasicAuth:
        #     Translate the client X.509 into a Basic Authorisation.  This means that
        #     the standard Auth/DBMAuth methods can be used for access control.  The
        #     user name is the `one line' version of the client's X.509 certificate.
        #     Note that no password is obtained from the user. Every entry in the user
        #     file needs this password: `xxj31ZMTZzkVA'.
        #   o ExportCertData:
        #     This exports two additional environment variables: SSL_CLIENT_CERT and
        #     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
        #     server (always existing) and the client (only existing when client
        #     authentication is used). This can be used to import the certificates
        #     into CGI scripts.
        #   o StdEnvVars:
        #     This exports the standard SSL/TLS related `SSL_*' environment variables.
        #     Per default this exportation is switched off for performance reasons,
        #     because the extraction step is an expensive operation and is usually
        #     useless for serving static content. So one usually enables the
        #     exportation for CGI and SSI requests only.
        #   o StrictRequire:
        #     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
        #     under a "Satisfy any" situation, i.e. when it applies access is denied
        #     and no other module can change it.
        #   o OptRenegotiate:
        #     This enables optimized SSL connection renegotiation handling when SSL
        #     directives are used in per-directory context.
        #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

        #   SSL Protocol Adjustments:
        #   The safe and default but still SSL/TLS standard compliant shutdown
        #   approach is that mod_ssl sends the close notify alert but doesn't wait for
        #   the close notify alert from client. When you need a different shutdown
        #   approach you can use one of the following variables:
        #   o ssl-unclean-shutdown:
        #     This forces an unclean shutdown when the connection is closed, i.e. no
        #     SSL close notify alert is send or allowed to received.  This violates
        #     the SSL/TLS standard but is needed for some brain-dead browsers. Use
        #     this when you receive I/O errors because of the standard approach where
        #     mod_ssl sends the close notify alert.
        #   o ssl-accurate-shutdown:
        #     This forces an accurate shutdown when the connection is closed, i.e. a
        #     SSL close notify alert is send and mod_ssl waits for the close notify
        #     alert of the client. This is 100% SSL/TLS standard compliant, but in
        #     practice often causes hanging connections with brain-dead browsers. Use
        #     this only for browsers where you know that their SSL implementation
        #     works correctly.
        #   Notice: Most problems of broken clients are also related to the HTTP
        #   keep-alive facility, so you usually additionally want to disable
        #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
        #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
        #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
        #   "force-response-1.0" for this.
        BrowserMatch "MSIE [2-6]" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        # MSIE 7 and newer should be able to use keepalive
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
        
        SSLProtocol all -SSLv2
        SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

</VirtualHost>
</IfModule>
La configuration des connexions SSL est maintenant terminée. Nous verrons comment l'utiliser au travers de différents services (Web, FTP, ....)

 

Valid XHTML 1.0 TransitionalValid CSS!

Copyright © 2011 Benjamin GAGNEUX. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.