framboise314.fr

Bonjour,

En fait tu as trois demandes.

1 - Interdire de lire le contenu du dossier lorsque l'on entre http://www.domaine.com/dossier/ et qu'il n'y a pas de page par défaut.
Dans ce cas, c'est la directive "Options -Indexes" qui va interdire la lecture du dossier, et retourner une erreur 403.

2 - Lorsque l'on entre l'adresse d'une page inexistante, obtenir une erreur.
C'est le système par défaut qui retourne l'erreur 404.

3 - Avoir des pages erreurs personnalisées.
Par défaut, apache à ses propres pages par défaut d'erreur, mais il est possible de les personnaliser.
Soit dans le fichier de configuration d'Apache, soit dans le htaccess en ajoutant "ErrorDocument 404 /errors/404.html"
Pour les erreurs 403 tu peux ajouter : "ErrorDocument 403 /errors/403.html"
Il faut bien entendu créer ces pages, tu peux également faire de même avec toutes les autres erreurs.

domi a écrit :Bonjour,

En fait tu as trois demandes.

1 - Interdire de lire le contenu du dossier lorsque l'on entre http://www.domaine.com/dossier/ et qu'il n'y a pas de page par défaut.
Dans ce cas, c'est la directive "Options -Indexes" qui va interdire la lecture du dossier, et retourner une erreur 403.

2 - Lorsque l'on entre l'adresse d'une page inexistante, obtenir une erreur.
C'est le système par défaut qui retourne l'erreur 404.

3 - Avoir des pages erreurs personnalisées.
Par défaut, apache à ses propres pages par défaut d'erreur, mais il est possible de les personnaliser.
Soit dans le fichier de configuration d'Apache, soit dans le htaccess en ajoutant "ErrorDocument 404 /errors/404.html"
Pour les erreurs 403 tu peux ajouter : "ErrorDocument 403 /errors/403.html"
Il faut bien entendu créer ces pages, tu peux également faire de même avec toutes les autres erreurs.

C'est bien ça !!!
Je vais tester ces options mais déjà là, ça marche pas du tout !!!
A voir !!!

Bon...

1er petit retour sur l'utilisation des CA "officiels" gratuits !!!

* Startssl.com :

- création du certificat rapide et simple, malgré que tout est "in english dans le texte" : il suffit de faire un openssl req -newkey rsa:2048 -keyout yourname.key -out yourname.csr sur son serveur et de copier le contenu du .csr, les certificats .crt (root_bundle + domaine) sont zippés pour tous les serveurs web (IIS, Apache, Ngix et autres)
- la mise en place sur le serveur est simple et expliquée

* LetsEncrypt :

- il suffit d'installer un outil (Cerbot), de lancer une ligne de commandes et tout est mis en place (configuration Apache, etc...)

Le Résultat :

- Startssl.com ==> ne fonctionne pas !!!
Après ouverture d'un ticket sur leur support on m'informe de ceci :
Certificates issued after 21.10.2016 are distrusted in Chrome, Firefox and Safari browsers. Chrome 57+ distrusts most of still valid certificates.
At the moment we have an interim solution only for Class 3 OV and Class 4 EV certificates.

En clair, leurs certificats gratuits ne fonctionnenent pas mais une solution "temporaire" ( ) existe : générer des certificats de classe 3 ou 4..........payants !!!
Ben voyons !!!

- LetsEncrypt ==> création des certificats en erreur !!!
Message :
Failed authorization procedure. mondomaine.fr (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to xxx.xxx.xxx.xxx:443 for TLS-SNI-01 challenge

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

Domain: mondomaine.fr
Type: connection
Detail: Failed to connect to xxx.xxx.xxx.xxx: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.

Je vérifie sur mon gestionnaire de domaine (OVH) ==> OK, pas soucis :
mondomaine.fr. 0 In xxx.xxx.xxx.xxx
==> c'est bien la même @IP

Maintenant, comme j'ai mis en place une redirection de port sur ma box, peut-être que ce serait du à ça... J'ai créé un post sur le forum de LetsEncrypt à ce sujet... A suivre !!!

On avance.... On avance, on avance !!! Lentement, oui... Mais sûrement !!!

J'aime bien la solution "on offre une solution gratuite, mais si vous souhaitez que cela fonctionne, il faut la solution payante"

Retour sur la prise de certificats SSL/HTTPS sur letsencrypt !!!

Après maintes tentatives, j'ai enfin réussit à générer des certificats SSL/HTTPS.
J'y ai passé des heures à comprendre, avec l'aide d'un ingénieur de chez Cerbot sur le forum de Letsencrypt... Tout ça pour constater (assez étrangement) que j'étais obligé de rediriger le port 80 en entrée de ma box vers le port 8080 de mon RPI, donc changement du port en écoute etc... Le temps de générer les certificats car leur outil a besoin d'accéder au domaine par le port 80... et il n'y arrivais pas...

Je configure Apache, stop et start... Je teste...
Et là, BOUM... Ça ne marche pas !!!

Message quand je tente un https://www.mondomaine.fr:xxxx/monsite/ en utilisant Google Chrome sur mon smartphone, j'obtiens ceci:
Votre connexion n'est pas privée.............
NET::ERR_CERT_COMMON_NAME_INVALID

Dans errorlog Apache, je vois ceci :
[Wed Mar 15 21:51:21.487842 2017] [ssl:info] [pid 17841] (70014)End of file found: [client @IP_smartphone:30517] AH01991: SSL input filter read failed.

Et quand je fais un service apache 2 status, je vois ceci :
The SSLCertificateChainFile directive is deprecated

Je tourne en rond et ça me crispe !!!


J'avance... Doucement mais sûrement !!!

Salut. Tu utilises un DNS dynamique ? ou tu as une IP fixe ?

Si tu utilises le port 443, tu n'as pas besoin de préciser le numéro de port dans ton URL. Du moment où tu mets HTTPS, ça passe par le 443. Par contre, es-tu sûr que tu n'as pas un conflit de port ? Tu es sûr que ta redirection fonctionne correctement ? Une façon de le vérifier est de faire une redirection du 443 sur le 80, et cette fois, d'essayer d'accéder par http://xxxxxxxxxx:443 pour voir si tu vois ton contenu en HTTP en entrant par le port 443. Si tu as le même message d'erreur, c'est que peut-être tes requêtes sur le port 443 ne vont pas où tu crois.

Let's encrypt fonctionne très bien en gratuit. Les certificats sont toutefois à renouveler tous les trois mois. A savoir.

Ton message "Name invalid" vient du contenu de ton certificat. Je reviens à la question ci-dessus: DNS dynamique ou IP Fixe ? Que déclares-tu dans ton certificat comme nom de domaine ? Est-ce que dnslookup <le-nom-que-tu-mets-dans-ton-certificat> 8.8.8.8 retourne bien la même IP que te retourne whatismyip.com ?

Si le nom de domaine indiqué dans le certificat ne correspond pas à ce qui est retourné par les serveurs DNS, ton certificat sera en erreur.

rebeldu31 a écrit : J'y ai passé des heures à comprendre, avec l'aide d'un ingénieur de chez Cerbot sur le forum de Letsencrypt... Tout ça pour constater (assez étrangement) que j'étais obligé de rediriger le port 80 en entrée de ma box vers le port 8080 de mon RPI, donc changement du port en écoute etc... Le temps de générer les certificats car leur outil a besoin d'accéder au domaine par le port 80... et il n'y arrivais pas...

C'est tout à fait normal, c'est leur moyen de vérifier que la machine depuis laquelle a été faite la demande de certificats a bien le même nom de domaine que celui du certificat demandé.
Tu fais la demande pour mondomaine.fr auprès de let's encrypt. Le logiciel qui fait la demande (certbot) écoute alors sur le port 80 une validation de la part de let's encrypt.
De son côté, let's encyript cherche à joindre certbot sur mondomaine.fr:80


concernant l'autre erreur, (NET::ERR_CERT_COMMON_NAME_INVALID), après quelques rapide recherche, cela serait un bug de Chrome....
Utilises-tu Chrome ? Si oui, qu'est ce que ça donne avec un autre navigateur ?

Salut,

En plus de ce qui est dit plus haut sur le nom de serveur et surtout sur l'IP dynamique ou pas, la ligne suivante m'interpelle :

rebeldu31 a écrit : Et quand je fais un service apache 2 status, je vois ceci :
The SSLCertificateChainFile directive is deprecated

Deprecated indique qu'elle ne doit plus être utilisée : il faut donc que tu regarde dans la doc de la version d'Apache que tu utilises par quoi elle est remplacée (par exemple, sur cette page).
D'ailleurs, vu tous les changements de syntaxe qu'ils ont introduit entre la 2.2 et la 2.4, j'ai du mal a comprendre pourquoi ils n'ont pas bumpé la version vers la 3.0 histoire de bien montrer qu'il y a des impactes importants ...

Bon... C'est réglé !!!

Youpiiiiiiiiii !!!



Problèmes :

- impossibilité de générer mes certificats Letsencrypt via le port 80
- impossibilité de certifier www.mondomaine.fr

Résolutions :

- j'ai pu générer les certificats pour mondomaine.fr ET www.mondomaine.fr avec des options de la commande "cerbot"
==> aidé et guidé par un ingénieur de chez Cerbot sur le forum de Letsencrypt
Letsencrypt n'autorise pas la certification *.mondomaine.fr ni en local (192.168.x.x)

- étrangement (ou c'est peut-être normal), je n'ai pu générer les certificats qu'en faisant les manip suivantes :
. autoriser le port 80 de l'extérieur sur ma box
. rediriger le port 80 externe vers le port 8080 interne
. faire écouter Apache sur le port 8080 et non 80

==> Je ne sais pas pourquoi mais sans ces manips, impossible de générer quoi que ce soit !!!

Donc, je teste, en utilisant Chrome de mon smartphone...
Et là.... SUPER !!!!
Tout fonctionne parfaitement... le "https" n'est plus barré, je n'ai plus de message de sécurité....

AU TOP !!!

Donc, je recommande Letsencrypt pour sa simplicité de génération des certificats, et pour son forum !!!

Me reste donc la partie "sécurisation" à traiter...

Salut,

merci pour l'information de plus je ne connaissais pas Certbot je fais encore tout a la main, va vraiment falloir que je regarde ça de beaucoup plus près