Bonjour à toutes et à tous,
Je fais actuellement tourner un site ( geraldine-rey-deschamps.com) dont le DNS redirige vers un VPS ( 37.187.225.76 ). Je viens de générer un certificat pour que le site soit accessible en https.
Ça marche (dans le sens où le site affiche bien le front en https) mais je ne peux plus charger mon API.
Voici le message d'erreur : 
J'ai cherché sur internet et j'ai trouvé cette solution
>
Et voici le message d'erreur 
En fait si vous accéder à http://37.187.225.76:8090/api/post vous recevez le résultat de l'api mais avec https cela ne marche plus. Je ne comprend pas trop car les DNS de mon nom de domaine pointe vers l'IP du VPS donc j'aurais pensé que le certificat été également disponible dessus.
Je pense avoir donc 2 solutions :
- créer un certificat pour l’adresse IP (et j'ai beau essayer ça me refuse l'IP car il ne s'agit pas d'un nom de domaine)
- contourner le message d'erreur Mixed Content
Si vous avez une idée de comment résoudre le problème je suis fortement preneur
Promis je ne viens plus vous embêter après, merci pour l'aide que vous m'avez apporté jusqu'à maintenant !
Bonjour,
Remplacez l'IP par le nom de domaine pour vos appels API
mais je ne peux plus charger mon API
A partir du moment où votre page est en https, tout doit passer en https sinon votre navigateur (Edge, Firefox) va déclarer un défaut de sécurité.
Vous avez deux possibilités:
- soit votre API doit aussi discuter en https. S'il discute en http sur le port 8090 ça ne sert à rien de vouloir lui parler en https.
- soit dans votre serveur web (Apache) vous devez configurer un sous-répertoire virtuel comme proxy qui redirige vers http://127.0.0.1:8090 qui est votre API.
Donc sur le "fil internet" il n'y a que du https qui passe.
Si ça fonctionne vous pouvez blinder votre sécurité en ne reliant (bind) votre API qu'à l'adresse IP 127.0.0.1 , en conséquence le port 8090 non sécurisé ne serait plus accessible depuis l'internet.
C'est encore quelque chose de nouveau pour vous :)
Bonjour,
Remplacez l'IP par le nom de domaine pour vos appels API
J'ai essayé avec postman et cela renvoi une erreur 404, il essaye d'acceder à un sous dossier /api/post/
soit votre API doit aussi discuter en https. S'il discute en http sur le port 8090 ça ne sert à rien de vouloir lui parler en https.
soit dans votre serveur web (Apache) vous devez configurer un sous-répertoire virtuel comme proxy qui redirige vers http://127.0.0.1:80901 qui est votre API.
Je n'arrive pas à générer de certificat pour l'adresse IP donc impossible de discuter en https avec l'api je vais essayer de me tourner vers la seconde solution même si de prime abord je n'ai pas bien compris, je vais allé fouiller internet avec ces éléments, merci !
L'algorithme d'OVH étant assez pertinent il m'a proposé en bas de mon topic celui-ci : https://community.ovhcloud.com/t/13677
Où vous avez proposez mon cher Fritz un lien vers la doc de NodeJs.
Alors déjà j'avais un http.createServer donc forcement ça allait poser problème, je l'ai changé en https et j'ai généré un certificat auto signé. Je m'attendais à un échec mais ça n'est qu'un demi échec je suis bien en https mais "non sécurisé" du fait que j'ai utilisé un certificat auto-signé.
Je pense avoir compris ce qu'il me reste à faire, obtenir un certificat lets encrypt et remplacer le fichier key.pem par le nouveau en le plaçant simplement à la place de l'autre via FileZila ??
Merci pour ton expertise je veux vraiment reprendre la finition front du site lol
ps : le bout de code que j'ai remplacé dans server.js pour ceux qui passeront par là
Ancien code
const http = require("http");
const app = require("./app");
const server = http.createServer(app);
Nouveau code
const https = require("https");
const fs = require("fs");
const app = require("./app");
[…]
const options = {
key: fs.readFileSync("key.pem"),
cert: fs.readFileSync("cert.pem"),
};
const server = https.createServer(options, app);
Je n'arrive pas à générer de certificat pour l'adresse IP
Puisque vous avez un certificat pour votre site web, allez faire un tour dans le répertoire /etc/letsencrypt/live ; c'est normalement là que se trouvent les certificats et les clés privées.
Si votre API utilise le même nom de domaine, utilisez le certificat et la clé qui se trouvent déjà à cet endroit.
Désolé mais ça me parait pas clair. Un certificat SSl (let's encrypt) est attaché à une IP via un nom de domaine ou un sous domaine.
J'ai jamais entendu parler d'un certificat SSL let's encrypt pour une IP (je me trompe peut être.)
J'ai jamais entendu parler d'un certificat SSL let's encrypt pour une IP
Justement, si le site web est example.com:443 et l'API est sur example.com:8089 ils peuvent présenter le même certificat qui authentifie example.com.
Tout à fait.
Du coup pourquoi vouloir utiliser une IP pour faire les requêtes API ?
Du coup pourquoi vouloir utiliser une IP pour faire les requêtes API ?
On attend un retour de @JulesD4 , il a toutes les cartes en mains.
Je voulais résoudre le problème avant de vous répondre mais comme je n'y arrive pas je vous fait un petit retour
Justement, si le site web est example.com:443 et l'API est sur example.com:8089 ils peuvent présenter le même certificat qui authentifie example.com.
Tout à fait.
Du coup pourquoi vouloir utiliser une IP pour faire les requêtes API ?
Et oui évidement je n'avais pas ajouté le port 8090 lors de l'appel API via l'url du nom de domaine, forcément je recevais une erreur 404…
Du coup avec `httpCreateServer(app)` je peux faire mon appel en http, cool le problème d'utiliser l'ip est réglé mais ça ne marche pas en https
Je fais donc `httpsCreateServer(app)`et là voici l'erreur sur chrome quand je fais l'appel API directement dans l'url :
Et `SSL_ERROR_NO_CYPHER_OVERLAP`sur Firefox qui d'ailleurs quand l'appel est fait depuis le client (via react) me renvoi
`Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://geraldine-rey-deschamps.com:8090/api/post/`
Donc là je ne comprend pas trop, l'API est simplement situé dans un dossier de l'appli front je ne vois pas pourquoi CORS vient m'embêter ici (CORS qui commence à très bien se placer dans la liste des erreurs que j'apprécie le moins soit dit en passant :') )
J'ai essayé de passer en options de `httpsCreateServer(options, app)`les certificats situé dans /etc/letsencrypts/live mais je rencontre une permission denied (même en changeant les droit d'accès en 777 ce qui doit être de toute manière catastrophique pour la sécurité).
J'essaye un maximum de vous solliciter le moins possible je sens que je suis tout à la fin du problème vraiment merci pour votre aide !
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin »
https://ubiq.co/tech-blog/set-access-control-allow-origin-cors-headers-apache/
https://geraldine-rey-deschamps.com:8090
D'après https://tls.imirhil.fr/tls/geraldine-rey-deschamps.com:8090
1deschamps.comdeschamps.com - 2001:41d0:404:300::976 : 8090
Erreur durant l’analyse : TLS seems not supported on this server
1deschamps.comdeschamps.com - 37.187.225.76 : 8090
Erreur durant l’analyse : TLS seems not supported on this server
permission denied
Faites un cron qui copie les clés, une fois par jour.
Ok alors le problème venait que je lançais
`pm2 start ecosystem.config.js` depuis mon utilisateur root
J'ai donc créé un nouveau user
Ensuite juste à mettre dans le serveur
const options = {
key: fs.readFileSync( "../../../../etc/letsencrypt/live/1deschamps.com/privkey.pemdeschamps.com/privkey.pem"),
cert: fs.readFileSync("../../../../etc/letsencrypt/live/1deschamps.com/cert.pemdeschamps.com/cert.pem"),
};
const server = https.createServer(options, app);
Et c'est tout bon ! Enfin presque (évidement lol), ça ne marche pas sur mozzila à cause de la CORS Policy mais ce sera résolu avec le lien de TTY.
Merci à tout les deux, excellente soirée / journée !!