Avec la généralisation du https par les navigateurs, les sites doivent avoir un certificat SSL.
Si vous utilisez MAMP ou MAMP Pro comme serveur local pour développer vos sites, vous pouvez lui demander de générer un “certificat SSL auto-signé” pour chacun d’eux. Toutefois, les navigateurs identifient qu’il s’agit d’un certificat auto-signé et affichent une alerte ou une page d’avertissement plutôt anxiogène.
Heureusement, MacOS X permet de “forcer” l’approbation du certificat auto-signé afin d’accéder au site sans avoir à subir ces avertissements. Ce tutoriel vidéo vous explique en 5 minutes le pourquoi et le comment.
Bonjour,
Ce court tuto pour répondre à une problèmatique qui revient assez souvent lorsqu’on crée un site en local avec Mamp ou Mamp Pro et qui concerne les certificats SSL auto-signés.
Bien qu’ayant généré le certificat SSL, lorsqu’on accède au site via un navigateur, on obtient une alerte ou une page assez anxiogène nous informant que la connexion n’est pas privée et évoquant même des individus malveillants tentant de subtiliser nos précieuses informations personnelles.
Dans le cas présent, s’agissant d’un site en local, c’est-à-dire un site qui est hébergé sur notre propre ordinateur, ce type de message n’est pas justifié. Mais le navigateur n’est pas en mesure de détecter cette configuration, il se fait ‘gruger’ et nous affiche donc cette alerte.
Dans les faits, qui plus est, le navigateur se trompe : la connexion est bien ‘privée’, c'est-à-dire que les flux de données échangés entre notre site local et le navigateur sont bien cryptés, on est en https://.
En revanche, là où il a raison, c’est que le certificat ne peut pas être ‘certifié’ par une autorité de certification. C'est la définition même d’un certificat ‘auto-signé’.
C’est comme si, lors d’un contrôle d’identité, l’agent de police n’avait que votre seule parole pour vous croire lorsque vous lui dites que vous n’avez pas vos papiers sur vous, mais que vous vous appelez Jacques Dupond. Faute d’une pièce d’identité certifiée, l’agent n’est pas en mesure de savoir si vous êtes bien celui que vous déclarez être.
C'est la même chose avec un certificat SSL ‘auto-signé’.
Nous allons donc en venir au réel sujet de cette vidéo et faire en sorte de ne plus afficher ce type de message lorsqu’on accède à notre site en local.
Pour cela, on va utiliser un logiciel fourni en standard avec MacOS X : il s'agit du ‘Trousseau d'accès’, que vous trouverez dans le dossier “Applications”… puis le dossier “Utilitaires”…
Voici le “Trousseau d'accès”… et on le lance.
Là, assurez-vous de cliquer sur ‘Certificats’ dans la rubrique ‘Catégories’ afin de réduire le contenu des éléments listés aux seuls certificats.
Dans la rubrique ‘Trousseaux’, vous pouvez sélectionnez soit “Session”, soit “Système” :
Le but de l’opération maintenant est d’ajouter au Trousseau notre certificat SSL et d’imposer sa validité.
Il nous faut donc le certificat en lui-même. Pour cela, on va le récupérer…
…dans Mamp.
On sélectionne le site concerné… et on accède à l’onglet SSL…
Là, on clique sur l’icône de dossier des fichiers de certificat “.crt”
On sélectionne le certificat du site concerné et on le fait glisser dans la fenêtre du “Trousseau d'accès”.
Dans le Trousseau d‘accès, je peux alors double-cliquer sur le certificat qu‘on vient d‘ajouter afin d‘en réveler le contenu et, surtout, la fonctionnalité qui nous intéresse : “Se fier”… que je déroule en cliquant sur le petit triangle.
Et là, je vais changer la valeur “Réglages par défaut”, que je remplace par “Toujours approuver”.
Je ferme la fenêtre du certificat…
Je valide la modification en saisissant mon mot de passe utilisateur… et je peux fermer le Trousseau d’accès.
Maintenant, si je rafraîchis la fenêtre du navigateur…
Tadaam ! Le site s’affiche désormais sans alerte et avec le petit cadenas tant recherché !
Voilà ! J'espère que ce petit tuto vous a plu et on se retrouve lors d’une prochaine vidéo.
Salut !
Pour illustrer une réponse faite sur le groupe facebook WordPress, WooCommerce Assistance, voici un exemple de carte “My Maps” Google. Il s'agit de cartes dites "statiques" (c'est-à-dire qu'on ne peut y interagir dessus via les API Google) mais qui disposent bien sûr du classique zoom et qu'on peut déplacer.
En cliquant sur l'icône à gauche de la barre de titre, un panneau latéral s'affiche. De là, en cliquant sur le nom d'un 'pin', on peut même obtenir un itinéraire pour se rendre à ce 'pin'.
Toujours dans la barre de titre, à droite, une première icône permet de partager la carte, la seconde icône permet d'afficher la carte en grand dans une nouvelle fenêtre.
L'intérêt de ces cartes Google, est qu'elles sont très facile à intégrer et sont GRATUITES.
Vous trouverez un tuto expliquant comment créer/personnaliser ses propres cartes sur cet article (la première partie) : https://www.notuxedo.com/comment-creer-carte-google-maps/
L’un des fichiers le plus convoité par les hackers est le wp-config.php de votre installation WordPress. En effet, ce fichier contient, notamment, les informations permettant de se connecter à la base de données. De là, le pirate aura accès à tout le contenu de votre site : les utilisateurs, les emails, il pourra modifier ou supprimer les pages du site, les articles de blog ; si vous avez une boutique, il aura accès à toutes les coordonnées des clients, etc.
Pour renforcer la sécurité de ce fichier sensible, je vous propose une astuce toute simple et à la portée de tous.
Le meilleur moyen de protéger le fichier wp-config.php est de passer par le .htaccess afin de le rendre inaccessible aux connexions extérieures.
Toutefois, tout le monde n’est pas forcément à l’aise avec ce fichier et ses règles d’écriture.
C’est pourquoi je vous propose une autre solution tout aussi efficace et qui n’est pas contradictoire avec le .htaccess : libre à vous de cumuler les deux !
Cette astuce s’appuie sur une fonctionnalité de WordPress :
si WordPress ne trouve pas le fichier
wp-config.php, il va le chercher au niveau supérieur de l’arborescence. Et s’il ne le trouve pas, il remonte d’un autre niveau. Et il le fait encore, si nécessaire… jusqu’à atteindre la racine du disque.S’il n’a toujours rien trouvé, alors il part du principe qu’il s’agit d’une nouvelle installation et affiche l’écran de configuration.
Par exemple, imaginons un dossier “Parent”, à l’intérieur duquel se trouve un dossier “Enfant”. Et dans ce dossier “Enfant” se trouve notre installation WordPress :
Maintenant, déplaçons le fichier wp-config.php dans le dossier “Parent” :
En fermant le dossier “Enfant”, c'est tout de suite plus évident : le fichier wp-config.php est désormais tout seul dans le dossier “Parent”. Les autres fichiers WordPress sont restés dans le dossier “Enfant”.
— « OK ! C’est bien joli tout ça, mais en quoi cela sécurise mon wp-config.php ? »
Déjà, le simple fait de le déplacer va rendre perplexe le pirate, et, a minima, le retarder.
Mais effectivement, l’astuce ne réside pas dans ce seul déplacement…
Chez la plupart des hébergeurs, vous disposez d’un “espace disque”.
Cet espace disque est généralement constitué d’un dossier principal, votre “racine” (root), contenant d’autres dossiers : probablement un dossier pour les sauvegardes, peut-être un dossier “cloud”, un dossier de statistiques, etc. et bien sûr le dossier dans lequel vous placez votre (vos) site(s) internet.
Ce dossier porte souvent le nom “www” ou “web” ou “public”…
Par exemple, voici une partie d'un espace disque “racine” chez l’hébergeur Infomaniak :
À la différence des autres, le dossier “www” (ou “web” ou…) est accessible depuis internet. C’est son but : que tout un chacun puisse accéder à son contenu.
En revanche, il n’en est pas de même des autres dossiers. Eux, sont protégés. On ne peut pas y accéder depuis internet. Du moins, pas sans s’être préalablement identifié.
Puisque la racine de votre hébergement est protégée, inaccessible depuis les navigateurs, c’est un lieu idéal pour notre wp-config.php.
Déplaçons-le !
Désormais, le fichier wp-config.php est à l’abri de la plus grande majorité des hackers, bien protégé.
Si vous avez plusieurs installations WordPress dans un même espace disque, tenez-en compte. Ne tentez pas de mettre tous vos wp-config.php à la racine : chacun d'eux écrasera le précédent. Il ne peut y avoir qu'un seul fichier de même nom dans un même endroit (dossier ou racine) !