J’ai deux problèmes (en fait j’en ai plus, mais ce blog n’est pas une thérapie, c’est pour partager)

Premier problème, sur mon serveur vps chez OVH (Debian 8), j’ai la désagréable sensation, pour ne pas dire certitude que la fonction mail de php ne fonctionne pas.

Que faire ?

Installer un serveur mail simple et efficace. Exim4 est notre homme. Mais il n’est pas configurer. Voir pas installé.

On se dirige vers la première ligne : Distribution directe par SMTP (site Internet)

Et dans Nom de courrier du système il faudra lui mettre votre nom de domaine, par ex : monsite.com
Ainsi que dans Autres destinations dont le courrier doit être accepté
J’ai laisser les autres options par défaut.

C’est le moment de vérifier si ça marche

Vous pouvez faire un test avec un fichier php sur votre serveur :

Le mail est envoyé, victoire !
Il est dans le spam… tout n’est pas perdu.

 

Second problème, gmail classe inévitablement le courrier dans les spams. Même si l’adresse mail du serveur est dans mes contacts.

En regardant le détail des mails, j’ai vu que l’IP v6 était utilisée. Ce n’est pas un problème en soit.
Si ce n’est que le SPF en qui Gmail fait confiance est paramétré sur l’IP v4 sur mon serveur OVH et que je ne peux pas le faire pointer vers l’IP v6.

Solution, demander à Exim4 d’envoyer en IP v4 en ajoutant à la fin de /etc/exim4/exim4.conf.template ceci :

et relancer le service :

 

Troisième problème, gmail ne classe plus le courrier dans les spams. Victoire ! Mais affiche un point d’interrogation à côté de mon nom de domaine quand j’affiche le message avec ce texte quand je le survol :

“Gmail n’a pas pu confirmer que ce message a bien été envoyé par monsite.com (et non par un spammeur).”

Ce tuto s’arrête ici. L’objectif premier est rempli, le smtp fonctionne et les mails ne partent pas dans les spam.

Pour résoudre ce dernier problème il faut générer deux clés RSA, une publique et une privée, mettre la clé publique dans les DNS… l’autre dans le mail. Beaucoup de manipulations, n’en n’ayant pas le besoin dans l’immédiat je vais m’en passer.

Le titre de l’article est mensonger. Je ne vais pas détailler, la procédure pour installer Let’s Encrypt, car c’est très bien fait sur cette page :

https://www.human-geek.com/installer-lets-encrypt-sur-un-vps-ovh/

Rapide résumé (pour comprendre allez voir le tuto sur human-geek.com)

Et arrivé à ce point vous devriez avoir le choix du ou des domaines pour activer le https… oui mais pas chez moi, rien du tout, il me propose de les ajouter à la main et après ça plante !

PAS DE PANIQUE

Voici les 4 erreurs que j’ai rencontré en installant Let’s Encrypt:

 

1 . Le port 443 doit être libre

Si vous avez configuré votre accès SSH sur le port 443… et bien retour sur le port 22 obligatoire.

Le 443 doit être disponible sous peine de ne pas comprendre pourquoi le script bug.

 

2 . Let’s Encrypt ne trouve pas les noms de domaine

Le virtual host d’Apache est en cause, même ma super config plante à ce stade.

Les régles à respecter pour que ça marche :

  1. Un seul nom de domaine par fichier de configuration /etc/apache2/sites-available/
  2. Pour voir votre nom de domaine proposé avec et sans le www il faut commencé la config ainsi :

    Dans mon tuto sur la configuration d’un virtual host avec gestion automatique des sous domaines, j’ai besoin de cette ligne :

    Aucun soucis, les ServerAlias sont cumulables, donc :

Vous pouvez maintenant relancer le script :

Et reprendre le tuto sur human-geek.com

En cas de pépins, revenez ici.

 

3 . Firefox m’affiche un avertissement concernant du contenu mixte et bloque certains éléments

Comme détaillé sur la page officielle : Le blocage du contenu mixte avec Firefox

Simple, il y a dans votre code source au moins un lien en http:// au lieu de https://

Une bibliothèque javascript importé depuis un serveur ou comme moi cette balise :

Balise qui réglé le problème d’arborescence factise de l’url rewriting.

Il faut tout simplement ajouter un s à la fin du http :

Et Firefox affichera votre page https sans soucis !

 

4 . C’est bien joli mon gars, mais ta super config de la mort ne fonctionne plus

Crotte, vous vous souvenez du tuto : VirtualHost et nom de domaines sur un VPS OVH, ben ça déconne à plein gaz maintenant !

La raison, Let’s Encrypt ajoute quelques lignes dans vos virtual host dans /etc/apache2/sites-available/

A la toute fin, juste avant </VirtualHost> , vous pourrez voir ceci :

Sauf que pour la peine nos règles de ré-écriture avant sont ignorées, il faut donc déplacer les lignes ci-dessus juste en dessous de RewriteEngine on, exemple :