Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 08-06-2017 17:33:06

hamzouz
Membre
Inscription : 08-06-2017

Automatisation de CertBot

Bonjour tout le monde,

Actuellement en stage de fin d'études en DUT Réseaux & Télécom, le directeur de la boîte m'a demandé d'installer un système Debian sur un serveur. Ce serveur doit générer et stocker les certificats pour la mise en place de connexions HTTPS au sein du réseau local (pour accéder à l'interface web d'administration des équipements réseau par exemple). Mon tuteur m'a parlé de l'outil CertBot qui fonctionne avec un serveur web et une crontab en gros, d'après ce que j'ai saisi......
J'ai bien installé le système et le serveur web apache et crontab. j'ai autorisé le ssl sur apache, etc...
La question que je me pose c'est de savoir s'il serait possible d'automatiser CertBot. Je cherche à savoir si il est possible d'envoyer les certificats stockés sur le serveur aux équipements qui en ont besoin ?
Ou bien il est obligatoire d'installer CertBot sur les équipement que l'on veut sécuriser ??

En espérant que vous aurez bien compris mon problème, je vous souhaite tous une excellente soirée.

PS: j'aimerais bien régler ce problème au plus vite étant donné que mon stage s'arrête dans 2 semaines. Merci d'avance.

Hors ligne

#2 09-06-2017 16:30:27

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

Salut,

Je suis pas vraiment sûr d'avoir compris ce que tu veux faire.
Certbot permet de réclamer et renouveller automatiquement un certificat à Letsencrypt qui sera utilisé par ton serveur. Les clients (de ton serveur) vérifiront alors auprès de Letsencrypt l'authenticité de ton serveur.
Les certificats délivrés par Letsencrypt ne sont valides que 90 jours, Certbot permet de les renouveller automatiquement (via cron). C'est plus pratique que de renouvel^ler les certificats à la mano ^^

Sont-ce les équipements dont tu parles qui se connectent au serveur Debian ? (oui sont-ce ! tongue)

Ou bien veux-tu te servir de ton serveur Debian comme entité tierce de confiance ?

Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#3 12-06-2017 13:05:14

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Salut daufinsyd, désolé de ne pas avoir vu plus tôt ta réponse !

Je vais tenter d'expliquer un peu mieux mon problème. Je voudrais permettre la connexion en https à l'interface d'administration du routeur pfsense du réseau local. En fait, quand on tape dans l'URL le lien "https://192.168.1.254:666" le navigateur renvoie le message comme quoi la connexion est risquée. Je voulais donc mettre en place un serveur où est installé dessus apache et certbot et pouvoir envoyer à partir du serveur certbot le certificat dont a besoin le routeur pfsense afin de permettre la connexion en ssl sans le message de risque du navigateur.

Lorsque je rentre la commande qui va bien, on me retourne ce message d'erreur. Il faut obligatoirement acheter un nom de domaine pour pouvoir mettre certbot en place ?

C:\Users\Cefim\Desktop\clé\certbot.PNG

Hors ligne

#4 12-06-2017 13:25:53

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

aucun soucis ^^

À ma connaissance du moins, c'est en effet obligatoire (pour tous les certificats SSL). Au passage il n'est plus possible d'obtenir un certificat pour un nom intranet (il s'agit d'un standard).

Ceci étant dit, il s'agit d'une adresse privée, seuls les appareils au sein de ton LAN peuvent s'y connecter, est-ce du coup primordial ?

Pour ce que tu veux faire regarde comment ajouter une autorité de certification à ton navigateur. Ainsi tu n'aura plus ce message. wink

Je pense que ton image ne s'est pas correctement uploadé

Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#5 12-06-2017 14:06:38

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Je galère depuis ce matin dessus à tenter de trouver une solution mais je crois que tu as raison, je vais aller en parler au directeur.
Pour l'histoire du LAN, je lui avais dit lorsqu'il m'a confié cette tâche que je ne voyais pas l'intérêt de mettre ça en place pour les équipement réseaux, mais bon....
Je vais rechercher ça de suite, merci beaucoup beaucoup pour le temps que tu m'as accordé.

erreur retourné:

root@CertBot:/usr/local/sbin# certbot-auto --apache certonly -d routeur.cefim.lan
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
An unexpected error occurred:
The request message was malformed :: Error creating new authz :: Name does not end in a public suffix
Please see the logfiles in /var/log/letsencrypt for more details.

Hors ligne

#6 12-06-2017 14:32:57

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

C'était avec plaisir smile

En effet on ne peut pas enregistrer de nom de domaine se terminant par lan

https://publicsuffix.org/list/public_suffix_list.dat

Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#7 13-06-2017 11:35:37

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

J'ai encore un petit soucis .... lorsque j'essaie de générer un certificat pour le domaine suivant, on me retourne l'erreur ci-dessous.


IMPORTANT NOTES:
- The following errors were reported by the server:


   Domain: glpi.cefim.eu
   Type:   connection
   Detail: Failed to connect to 52.17.128.132:443 for tls-sni-01
   challenge


   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Hors ligne

#8 13-06-2017 13:49:06

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

À première vue le problème vient du fait que l'adresse donnée avec le port 443 n'est pas accessible.

Vérifie ta configuration afin de rendre le site accessible depuis le port 443 et réessayes.

Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#9 13-06-2017 14:19:20

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Encore une fois merci de prendre le temps d'étudier mon problème.

Tu pourrais me dire où est ce qu'on peut vérifier le port 443 ?

PS: le site que je cherche à sécuriser est glpi.cefim.eu et le domaine nous appartenant est cefim.eu

Merci.

Hors ligne

#10 13-06-2017 14:31:59

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

smile

le port 443 est celui associé à la connexion sécurisée (https).
Pour savoir s'il est ouvert tu peux utiliser nmap

nmap -v glpi.cefim.eu -p 443



Si ce n'est pas le cas vérfie que les pare-feux ne bloquent pas le dit-port.

S'il est ouvert vérifie que ton serveur écoute sur ce port (la méthode change selon que tu utilises nginx, apache, ...)


Une fois le port ouvert et le serveur écoutant sur celui-ci (et servant quelque chose), tu devrais pouvoir te connecter à https://glpi.cefim.eu avec ton navigateur wink


Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#11 13-06-2017 14:51:57

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

le port est fermé sur glpi.cefim.eu. Je sais pas comment on fait pour l'ouvrir étant donné que le site est avec une adresse IP publique.
Le serveur web que j'ai utilisé est apache. J'ai ajouté un nouveau vhost en spécifiant servername etc...

Je ne sais vraiment pas d'où vient l'erreur et ça m'énerve légèrement...... scratchhead.gifscratchhead.gifscratchhead.gif

Hors ligne

#12 13-06-2017 15:02:40

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

Pour ce il faut modifier les règles de pare-feu de ton entreprise pour autoriser les paquets communiquants sur le port 443 (et rediriger le traffic vers le serveur si ce n'est pas déjà fait). Cette étape est identique pour n'importe quel autre port. Mais pour le coup c,a dépend de ton entreprise (c'est le role de l'admin réseau de changer les ports ouverts/fermés).

Pour ton vhost c'est comme l'actuel vhost écoutant sur le port 80 à ceci près qu'il faut ajouter quelques lignes pour dire à apache qu'il s'agit d'une connexion sécurisée). tu devrais trouver ton "bonheur" sur le wiki d'apache wink

https://wiki.apache.org/httpd/NameBasedSSLVHosts


Edit : le fait que ce soit une adresse IP publique ne change pas fondamentalement les choses. Schématiquement, le routeur possède l'adresse IP publique (c'est le point d'accüs du monde extérieur au serveur), il faut donc qu'il redirige le port 443 vers ton serveur (via son adresse ip cette fois privée), et pour c,a le pare-feu ne doit pas bloquer le port 443.

Dernière modification par daufinsyd (13-06-2017 15:06:51)


Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#13 13-06-2017 15:06:59

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

je vais jeter un oeil au lien que tu m'a donné, c'est gentil de ta part.

L'administrateur, c'est moi depuis 3 mois et encore 1 dernière semaine donc je pense que je vais devoir m'y coller zen.gifzen.gifzen.gif.
Il faut modifier la table de redirections de ports dans l'interface d'administration du routeur c'est bien ça ?

Hors ligne

#14 13-06-2017 15:11:43

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

La vie de l'entreprise repose sur tes décisions ! lol

Chaque entreprise gère son réseau de manière différente, mais dans l'idée oui.

Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#15 13-06-2017 15:13:42

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Pauvre entreprise, j'ai envie de dire................ lol:lol::lol:
Merci beaucoup pour ton aide, je vais aller essayer puis je te tiens au courant !

Hors ligne

#16 14-06-2017 16:42:07

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Je suis parti vérifier, le site est héberger par AWS et lorsque je me connecte en tant qu'admin, aucune règle de filtrage n'est en place et le port 443 du HTTPS est autoriser.
Mais quand je lance le scan de ports, il me marque "state = closed".... comment c'est possible ?????
Aurais-tu une idée ? Ca commence à faire pas mal de temps que je suis là dessus et je suis persuadé que c'est une petite erreur de rien du tout (comme d'habitude lolilol).

Si tu pouvais m'accompagner sur la démarche à suivre pour la sécurisation d'un site via certbot, ça me rendrait un grand service !

Merciiiiiiii !!!!

Hors ligne

#17 14-06-2017 23:35:01

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

Haha, alors là c'est un petit piège de nmap. Pour lui "close" veut dire accessible mais aucun service n'écoute dessus (pour plus d'info sur les retours de nmap https://nmap.org/book/man-port-scanning-basics.html). XD Du coup c'est normal pour ton cas.

Configure un virtual host écoutant sur le port 443 (tu peux utiliser l'exemple de base d'apache juste pour vérifier que ça marche)

Si tu pouvais m'accompagner sur la démarche à suivre pour la sécurisation d'un site via certbot, ça me rendrait un grand service !



Bien sûr ! big_smile


Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#18 15-06-2017 09:43:29

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Configure un virtual host écoutant sur le port 443 (tu peux utiliser l'exemple de base d'apache juste pour vérifier que ça marche)



j'ai configuré mon virtual host comme ci-dessous:

NameVirtualHost 52.17.128.132

<VirtualHost 52.17.128.132:443>
        # The ServerName directive sets the request scheme, hostname and port t$
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        ServerName glpi.cefim.eu
        ServerAdmin hlakhal362@gmail.com
        DocumentRoot /var/www/cefim

        SSLEngine on
        SSLCertificateFile /etc/apache2/serv.crt
        SSLCertificateKeyFile /etc/apache2/server.key
 




Cependant, le chemin où sont stocké les certificats, je sais pas quoi mettre exactement....

Après avoir défini le port du virtualhost je redémarre le serveur apache et je test la commande certbot --apache c'est bien ça ?

Hors ligne

#19 15-06-2017 09:45:56

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

le service apache n'arrive pas à redémarrer.... Voici les logs renvoyés

[Thu Jun 15 06:25:04.167263 2017] [mpm_event:notice] [pid 14209:tid 3074565952] AH00489: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured -- resuming normal operations
[Thu Jun 15 06:25:04.176805 2017] [core:notice] [pid 14209:tid 3074565952] AH00094: Command line: '/usr/sbin/apache2'
[Thu Jun 15 09:45:51.362057 2017] [mpm_event:notice] [pid 14209:tid 3074565952] AH00493: SIGUSR1 received.  Doing graceful restart
AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist
[Thu Jun 15 09:45:51.402253 2017] [ssl:warn] [pid 14209:tid 3074565952] AH01906: 6dfde6ffc09d310919a7eeb31b94bea7.c2b21cdeae0fcb3e3a69c213d1e980dc.acme.invalid:443:0 server certificate is a CA cer$
[Thu Jun 15 09:45:51.402770 2017] [mpm_event:notice] [pid 14209:tid 3074565952] AH00489: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured -- resuming normal operations
[Thu Jun 15 09:45:51.402808 2017] [core:notice] [pid 14209:tid 3074565952] AH00094: Command line: '/usr/sbin/apache2'
[Thu Jun 15 09:45:58.305453 2017] [mpm_event:notice] [pid 14209:tid 3074565952] AH00493: SIGUSR1 received.  Doing graceful restart
[Thu Jun 15 09:45:58.364167 2017] [mpm_event:notice] [pid 14209:tid 3074565952] AH00489: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured -- resuming normal operations
[Thu Jun 15 09:45:58.364227 2017] [core:notice] [pid 14209:tid 3074565952] AH00094: Command line: '/usr/sbin/apache2'
[Thu Jun 15 09:57:59.760156 2017] [mpm_event:notice] [pid 14209:tid 3074565952] AH00491: caught SIGTERM, shutting down
[Thu Jun 15 09:58:01.146789 2017] [mpm_event:notice] [pid 15343:tid 3074557760] AH00489: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured -- resuming normal operations
[Thu Jun 15 09:58:01.147134 2017] [core:notice] [pid 15343:tid 3074557760] AH00094: Command line: '/usr/sbin/apache2'
[Thu Jun 15 10:15:06.485903 2017] [mpm_event:notice] [pid 15343:tid 3074557760] AH00491: caught SIGTERM, shutting down
[Thu Jun 15 10:15:55.579381 2017] [mpm_event:notice] [pid 15524:tid 3074451264] AH00489: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured -- resuming normal operations
[Thu Jun 15 10:15:55.579736 2017] [core:notice] [pid 15524:tid 3074451264] AH00094: Command line: '/usr/sbin/apache2'
[Thu Jun 15 10:26:16.369921 2017] [mpm_event:notice] [pid 15524:tid 3074451264] AH00491: caught SIGTERM, shutting down

Hors ligne

#20 15-06-2017 10:36:49

captnfab
Admin-Girafe
Lieu : /dev/random
Distrib. : Debian Jessie/Stretch/Buster/Sid/Rc-Buggy
Noyau : Linux (≥ 4.9)
(G)UI : i3-wm (≥ 4.13)
Inscription : 07-07-2008
Site Web

Re : Automatisation de CertBot

tu as vu l'erreur ? :

AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist


captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.

Hors ligne

#21 15-06-2017 10:47:19

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Oui, mais il me semble que ce répertoire doit être crée automatiquement lorsque l'on lance la commande certbo-auto non ?
Moi, il me met echec de connexion sur le port 443 et il ne génère aucun certificats nulle part...
Que me conseilles tu stp ? je suis à bout là....

Hors ligne

#22 15-06-2017 11:08:59

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

Dans les champs SSLCertificate... tu dois mettre le chemin vers ta clef utilisée pour le chiffrement et son certificat de vérification.

Ces deux fichiers tu peux soit laisser certbot les créer pour toi, soit les créer manuellement.
Pour l'instant je te conseil de commencer avec une clef que tu crées toi-même (avant d'utiliser certbot), afin de bien comprendre la base.

Il suffit pour cela de créer ta clef et la signer comme suit

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/server.key -out /etc/apache2/serv.crt



(Quelques questions te seront posées)

Voici un lien vers un tuto clair et simple https://www.digitalocean.com/community/ … r-debian-8

Dernière modification par daufinsyd (15-06-2017 11:10:00)


Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#23 15-06-2017 11:24:41

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Les fichiers .crt et .key sont présent dans le répertoire /etc/apache2/ssl
J'ai crée mon certificat, que faut il faire ensuite svp ?

Dernière modification par hamzouz (15-06-2017 11:31:53)

Hors ligne

#24 15-06-2017 14:12:13

daufinsyd
Membre
Lieu : 68, 63, Karlsruhe
Distrib. : Manjaro + Debian Stable + Xubuntu
Noyau : Linux 4.9-amd64
(G)UI : Plasma 5.10
Inscription : 02-02-2013
Site Web

Re : Automatisation de CertBot

il faut éditer ton virtual host pour qu'il les prenne en compte
(les lignes SSLCertificateFile et SSLCertificateKeyFile)

Suis les lignes du tuto en les adaptant à ton cas précis wink

Aspire V3-772G + SSD 850Evo
Intel i7-4790 - 12Go RAM - GTX460
Intel i7-6700 - 8Go RAM - AMD R9 280X 3Go - SSD 850Evo
Odroid C2, Raspberry Pi Zero

Hors ligne

#25 15-06-2017 16:34:25

hamzouz
Membre
Inscription : 08-06-2017

Re : Automatisation de CertBot

Lorsque j'utilise mes certificats auto-signé, ça ne fonctionne pas non plus..

root@CertBot:~# openssl s_client -connect glpi.cefim.eu:443
connect: Connection refused
connect:errno=111


Fichier vhost:

GNU nano 2.2.6                                                  Fichier : default-ssl.conf

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin webmaster@localhost
                ServerName glpi.cefim.eu:443
                DocumentRoot /var/www/html


                # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
                # error, crit, alert, emerg.
                # It is also possible to configure the loglevel for particular
                # modules, e.g.
                #LogLevel info ssl:warn


                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined


                # For most configuration files from conf-available/, which are
                # enabled or disabled at a global level, it is possible to
                # include a line for only one particular virtual host. For example the
                # following line enables the CGI configuration for this host only
                # after it has been globally disabled with "a2disconf".
                #Include conf-available/serve-cgi-bin.conf


                #   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/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/apache2/ssl/apache.crt
                SSLCertificateKeyFile /etc/apache2/ssl/apache.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
#   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 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


                                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>


# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Hors ligne

Pied de page des forums