OVH Community, votre nouvel espace communautaire.

SSL activé par défaut sur le mutu : une très très mauvaise idée


Daniel60
27/05/2016, 11h44
Le sous-domaine ne marche toujours pas sur le cluster006

vcasse
27/05/2016, 11h14
Citation Envoyé par G0ldDiggAA
J'ai le même souci que clems a rencontré. Mon ndd de pointait pas vers l'ip du cluster.
Je viens de voir que tout s'est bien propagé.

vcasse, est-ce-que tu pourrais également relancer le processus pour mon domaine bettingtracker.net s'il te plait ?

Je suis sur le cluster 007

Merci par avance.
C'est bon pour ton site

Cordialement,
Vincent

vcasse
27/05/2016, 10h22
Citation Envoyé par G0ldDiggAA
J'ai le même souci que clems a rencontré. Mon ndd de pointait pas vers l'ip du cluster.
Je viens de voir que tout s'est bien propagé.

vcasse, est-ce-que tu pourrais également relancer le processus pour mon domaine bettingtracker.net s'il te plait ?

Je suis sur le cluster 007

Merci par avance.
Salut G0ldDiggAA,

Le process est en cours. Si tu n'as rien de nouveau d'ici à cet après midi, post un message ici.

Cordialement,
Vincent

Binano
27/05/2016, 10h18
Ah d'accord, j'étais allé voir ce lien avant de signaler le problème ici... j'avais lu "La mise en prod est prévue cet après midi" donc comme nous sommes maintenant vendredi je pensais que c'était un nouveau problème.

vcasse
27/05/2016, 10h08
Citation Envoyé par Binano
Chez moi, ça redéconne ce matin sur le cluster003...
Le cluster 003 a été désactivé il y a deux jours. Toutes les informations et le suivi se fait dans la tâche travaux
http://travaux.ovh.net/?do=details&id=18027

Cordialement,
Vincent

shacreaw
27/05/2016, 10h07
Le cluster003 a été retiré du déploiement : http://travaux.ovh.net/?do=details&id=18027

"Ce mercredi, le cluster 003 a subi une attaque DDOS. La plus grosse depuis que nous utilisons le nouveau load balancing. Il a bien sur été pris en charge par l'anti DDOS OVH.

Cette attaque nous a permis d'identifier des améliorations possibles afin que les DDOS soient détectés beaucoup plus rapidement et qu'ils ne se fasse pas ressentir du tout par les visiteurs légitimes. Nous avons décidé de coder ces améliorations et de les déployer avant de continuer le déploiement de nos clusters.

Nous avons aussi retiré le cluster003 le temps de déployer ces améliorations."

Binano
27/05/2016, 09h31
Chez moi, ça redéconne ce matin sur le cluster003...

clems313
26/05/2016, 18h25
Citation Envoyé par vcasse
Dans le pire des cas, si tu ne vois rien de neuf d'ici demain, reposte un message ici même.
Je vais quand même refaire un arrêt par ici pour te confirmer que ça fonctionne maintenant !

Merci pour ton aide !

Daniel60
26/05/2016, 17h20
Cluster006 : Domaine OK, mais sous-domaine KO : SSL_ERROR_BAD_CERT_DOMAIN. Le sous-domaine a un password mais je ne pense pas qu'il y ai un rapport.
bd3699

G0ldDiggAA
26/05/2016, 17h15
J'ai le même souci que clems a rencontré. Mon ndd de pointait pas vers l'ip du cluster.
Je viens de voir que tout s'est bien propagé.

vcasse, est-ce-que tu pourrais également relancer le processus pour mon domaine bettingtracker.net s'il te plait ?

Je suis sur le cluster 007

Merci par avance.

vcasse
26/05/2016, 16h33
Citation Envoyé par clems313
Bonjour,

J'ai déjà réalisé cette modification il y a 2 jours. Ce devrait donc être bon pour lancer la génération du certificat.
Je ne sais pas du tout pourquoi le domaine pointait sur le CDN ceci dit, mais bon, pas grave !

Merci pour ton aide.
Bonjour,

Effectivement, je n'avais pas vu la modification. Je viens de relancer le processus. Il peut pendre une petite heure.
Dans le pire des cas, si tu ne vois rien de neuf d'ici demain, reposte un message ici même.

Cordialement,
Vincent

clems313
26/05/2016, 16h17
Citation Envoyé par vcasse
Bonjour clems313,

Je viens de regarder sur ton compte. Le certificat n'a pas été généré car ton traffic passe par l'ip du cdn (mais sans qu'il ne soit activé) : 213.186.33.82
Nous ne pouvons pas activer HTTPS sur cette ip étant donné que le CDN n'est pas encore compatible.

Pour le cluster 013, l'ip recommandée (FR) est 213.186.33.24. Tu peux la retrouver au sein de ton espace client au besoin.

Une fois que tu auras changé le pointage de ton nom de domaine, reviens ici, nous pourrons lancer la génération de ton certificat.
Bonjour,

J'ai déjà réalisé cette modification il y a 2 jours. Ce devrait donc être bon pour lancer la génération du certificat.
Je ne sais pas du tout pourquoi le domaine pointait sur le CDN ceci dit, mais bon, pas grave !

Merci pour ton aide.

vcasse
26/05/2016, 14h50
Citation Envoyé par clems313
Merci pour ces précisions, je comprends mieux maintenant !
Il s'agit du domaine "clan-anarkia.com".
Bonjour clems313,

Je viens de regarder sur ton compte. Le certificat n'a pas été généré car ton traffic passe par l'ip du cdn (mais sans qu'il ne soit activé) : 213.186.33.82
Nous ne pouvons pas activer HTTPS sur cette ip étant donné que le CDN n'est pas encore compatible.

Pour le cluster 013, l'ip recommandée (FR) est 213.186.33.24. Tu peux la retrouver au sein de ton espace client au besoin.

Une fois que tu auras changé le pointage de ton nom de domaine, reviens ici, nous pourrons lancer la génération de ton certificat.

Cordialement,
Vincent

clems313
26/05/2016, 14h43
Citation Envoyé par vcasse
Bonjour,

Si tu as le sslX.ovh.net où X = le numéro de ton cluster, cela signifie que le certificat n'a pas pu être généré pour ton compte.
Pourrais tu indiquer ton nom de domaine afin que l'on regarde pourquoi ?
Merci pour ces précisions, je comprends mieux maintenant !
Il s'agit du domaine "clan-anarkia.com".

vcasse
26/05/2016, 11h49
Citation Envoyé par Fredo-73
@vcasse
Bonjour Vincent
Juste une question.
Est-ce que tu sais dans quel ordre vous allez faire passer les prochains clusters ?
Simplement pour prévoir la période où il faudra être plus vigilant ...
Merci
Fred
Bonjour,

Nous avons bien un ordre défini. Mais il change souvent. Alors, pour éviter toute déception, on le communique pas

Cordialement,
Vincent

- - - Mise à jour - - -

Citation Envoyé par clems313
Salut,

Au risque de passer pour un gros noob, je vais quand même poser la question.

Je suis en hébergement mutualisé (Perso2014) et visiblement mon cluster peut bénéficier du HTTPS (cluster013).

Lorsque je me connecte sur mon site avec https, j'ai une erreur "Your connection is not secure", à juste titre, puisque "The certificate is only valid for ssl13.ovh.net" (et non pas pour mon domaine).

Je n'ai effectué aucune modification du .htaccess.
Je n'ai pas de CDN sur mon offre.
Mon domaine pointe bien vers l'adresse IP de mon hébergement web (je l'ai modifié hier, et ça ne fonctionnait pas mieux avant ).

Je rate quelque chose ?
Bonjour,

Si tu as le sslX.ovh.net où X = le numéro de ton cluster, cela signifie que le certificat n'a pas pu être généré pour ton compte.
Pourrais tu indiquer ton nom de domaine afin que l'on regarde pourquoi ?

Cordialement,
Vincent

Binano
25/05/2016, 08h56
Merci ! Ca fonctionne nickel maintenant !

nitrix-ud
25/05/2016, 08h50
Ca a l'air de fonctionner mais bizarrement quand je test mon site sur Google Webmaster "explorer comme Google", il me met un point d'exclamation devant "redirection" comme si elle n'était pas correcte et qu'il ne voyait pas le contenu de la page.
Je pense que c'est normal. Tu as bien une redirection de type 301. Ton search console devrait être avec ton adresse en https maintenant.

buddy
25/05/2016, 08h12
remplace
Code:
RewriteCond %{HTTP_HOST} !^www\.forum-velo-pliant\.fr$ [NC] 
RewriteRule ^(.*) http://www.forum-velo-pliant.fr/$1 [QSA,L,R=301]

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,QSA,R=permanent]
par
Code:
RewriteCond %{HTTP_HOST} !^www\.forum-velo-pliant\.fr$ [NC] 
RewriteRule ^(.*) https://www.forum-velo-pliant.fr/$1 [QSA,L,R=301]

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,QSA,R=permanent]
il faut aussi mettre https dans la configuration de phpbb

il faut aller dans le panneau d'administration puis
CONFIGURATION DU SERVEUR - Paramètres de cookie
Activer la version sécurisée du Cookie.

CONFIGURATION DU SERVEUR - Paramètres du serveur:
Vérifier que le paramètre "Forcer les paramètres URL du serveur" soit à Oui.
Indiquer https:// dans le protocole du serveur
Indiquez 443 en port du serveur.
Videz le cache de votre forum et les sessions dans l'accueil de l'administration.
source : https://www.phpbb-services.com/guide...9&article=8857

Binano
25/05/2016, 07h54
Petite question hors sujet mais maintenant que le certificat SSL fonctionne sur mon site j'aimerais combiné deux redirections proprement :

- Celle pour ajouter WWW à tout mes URL
- Celle pour rediriger HTTP vers HTTPS

Est-ce que c'est possible ?

J'ai testé ceci :
RewriteCond %{HTTP_HOST} !^www\.forum-velo-pliant\.fr$ [NC]
RewriteRule ^(.*) http://www.forum-velo-pliant.fr/$1 [QSA,L,R=301]

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,QSA,R=permanent]

Ca a l'air de fonctionner mais bizarrement quand je test mon site sur Google Webmaster "explorer comme Google", il me met un point d'exclamation devant "redirection" comme si elle n'était pas correcte et qu'il ne voyait pas le contenu de la page.

http://img15.hostingpics.net/pics/836955Capture.png

clems313
24/05/2016, 16h22
Salut,

Au risque de passer pour un gros noob, je vais quand même poser la question.

Je suis en hébergement mutualisé (Perso2014) et visiblement mon cluster peut bénéficier du HTTPS (cluster013).

Lorsque je me connecte sur mon site avec https, j'ai une erreur "Your connection is not secure", à juste titre, puisque "The certificate is only valid for ssl13.ovh.net" (et non pas pour mon domaine).

Je n'ai effectué aucune modification du .htaccess.
Je n'ai pas de CDN sur mon offre.
Mon domaine pointe bien vers l'adresse IP de mon hébergement web (je l'ai modifié hier, et ça ne fonctionnait pas mieux avant ).

Je rate quelque chose ?

Gaston_Phone
24/05/2016, 15h21
Moi aussi.

kingkurt
24/05/2016, 14h46
Citation Envoyé par Fredo-73
@vcasse
Bonjour Vincent
Juste une question.
Est-ce que tu sais dans quel ordre vous allez faire passer les prochains clusters ?
Simplement pour prévoir la période où il faudra être plus vigilant ...
Merci
Fred
Ça m'intéresse aussi !

Fredo-73
24/05/2016, 14h39
@vcasse
Bonjour Vincent
Juste une question.
Est-ce que tu sais dans quel ordre vous allez faire passer les prochains clusters ?
Simplement pour prévoir la période où il faudra être plus vigilant ...
Merci
Fred

Jikoo
24/05/2016, 01h10
Citation Envoyé par VincentAlex
Mais maintenant, qu'il y a ce nouveau SSL directement intégré dans les hébergements, quelle est la procédure pour utiliser celui là (gratuit) à la place du certificat payant qui me suffira amplement pour mon besoin ?
J'étais dans ce cas. Il faut que ton site pointe sur la bonne adresse IP.
Regarde mon post et les commentaires qui suivent:
https://forum.ovh.com/showthread.php...073#post669073

VincentAlex
23/05/2016, 23h00
Question connexe :

Sur mon site (neufbox4.org), j'ai un certificat SSL suite à la participation au béta test de été dernier. Il était gratuit pendant 1 an, mais si je veux le conserver, il me faudra payer.

Mais maintenant, qu'il y a ce nouveau SSL directement intégré dans les hébergements, quelle est la procédure pour utiliser celui là (gratuit) à la place du certificat payant qui me suffira amplement pour mon besoin ?

Merci.

Binano
23/05/2016, 22h09
Citation Envoyé par nitrix-ud
tu n'es pas encore concerné, d'où le message d'erreur... le navigateur vérifie le certificat (car en https) et balance le message d'erreur... quand ton site sera concerné, le navigateur vérifiera le certificat (qui sera bon) et la le htaccess fera son boulot.
Ca fonctionne !

nitrix-ud
23/05/2016, 14h16
Citation Envoyé par vcasse
Oui, nos ciphers sont un peu trop restrictifs : AES est chiffré au minimum en 256bits.
On regarde si cela a un impact sur la sécurité du SSL de le descendre en 128 bits pour java8.

Cordialement,
Vincent
Super Vincent, merci pour le retour

vcasse
23/05/2016, 12h19
Citation Envoyé par nitrix-ud
Dernière version 8u91
mais let's encrypt doit marcher avec java normalement..


Chrome et Edge ne les supportent plus... c'est clair que java, flash, silverlight, c'est du passé... mais bon c'est encore présent sur bcp de site et applications métiers..
Oui, nos ciphers sont un peu trop restrictifs : AES est chiffré au minimum en 256bits.
On regarde si cela a un impact sur la sécurité du SSL de le descendre en 128 bits pour java8.

Cordialement,
Vincent

nitrix-ud
20/05/2016, 20h48
Citation Envoyé par JBGO
Les ciphers utilisés par OVH sont AES 256 bit, surement incompatible avec l'applet ... quelle version de Java est utilisée ?
Dernière version 8u91
mais let's encrypt doit marcher avec java normalement..

Attention par contre concernant les applets Java, les navigateurs les supportent de moins en moins
Chrome et Edge ne les supportent plus... c'est clair que java, flash, silverlight, c'est du passé... mais bon c'est encore présent sur bcp de site et applications métiers..

JBGO
20/05/2016, 20h03
Citation Envoyé par nitrix-ud
@Vincent,

je viens de faire des tests sur un de mes sites sur le cluster006, le https fonctionne bien.

Par contre impossible de charger un applet java en https, comme je le pressentais précédemment...

j'ai l'erreur : handshake_failure

ça veut dire que java en https c'est impossible avec OVH ???
Les ciphers utilisés par OVH sont AES 256 bit, surement incompatible avec l'applet ... quelle version de Java est utilisée ?

Attention par contre concernant les applets Java, les navigateurs les supportent de moins en moins

nitrix-ud
20/05/2016, 18h36
@Vincent,

je viens de faire des tests sur un de mes sites sur le cluster006, le https fonctionne bien.

Par contre impossible de charger un applet java en https, comme je le pressentais précédemment...

j'ai l'erreur : handshake_failure

ça veut dire que java en https c'est impossible avec OVH ???

raoul-h
20/05/2016, 15h10
Citation Envoyé par Binano
Eh bien je voudrais que les pages de mon forum référencées sous google en https:// arrête de me renvoyer sur cette erreur
Bonjour, de quand date ton problème ?
Malheureusement pour toi, j'ai peur que ce qui est en train de se passer avec ton site ne soit exactement ce que j'avais prévu dans mon post initial, tu vas perdre beaucoup de visiteurs, tout comme des milliers de webmasters.
Il faut qu'OVH mette en place un OPT-IN de toute urgence pour le SSL (et pas un OPT-OUT qui n'est pas suffisant).

buddy
20/05/2016, 15h09
il faut adapter la configuration du forum quand ton cluster sera fait ...

les informations que l'on t'a donné sur phpbb sont les bonnes.

il faut suivre ce tutoriel : https://www.phpbb-services.com/guide...9&article=8857 à partir de §Comment rediriger mes visiteurs vers la version sécurisée de mon site ?

nitrix-ud
20/05/2016, 15h07
tu n'es pas encore concerné, d'où le message d'erreur... le navigateur vérifie le certificat (car en https) et balance le message d'erreur... quand ton site sera concerné, le navigateur vérifiera le certificat (qui sera bon) et la le htaccess fera son boulot.

Binano
20/05/2016, 14h55
Citation Envoyé par buddy
Tu veux faire quoi conrètement ?
Eh bien je voudrais que les pages de mon forum référencées sous google en https:// arrête de me renvoyer sur cette erreur :

sur ce lien fournit dans les résultats de google par exemple : https://www.binano.fr/viewtopic.php?t=48733

J'ai cette erreur :
Votre connexion n'est pas privée

Il se peut que des pirates soient en train d'essayer de dérober vos informations sur le site www.binano.fr (par exemple, des mots de passe, des messages ou des informations sur vos cartes de paiement). NET::ERR_CERT_COMMON_NAME_INVALID
si j'ôte le "s" de l'URL, ça fonctionne : http://www.binano.fr/viewtopic.php?t=48733

Cà marchera quand çà sera activé sur cluster003 (cf cette tache de travaux : http://travaux.ovh.net/?do=details&id=18027 )
Ah ? Donc il n'y a rien à faire ??? ça fonctionnera quelque soit l'hébergement mutualisé ?

buddy
20/05/2016, 14h45
Tu veux faire quoi conrètement ?
Le SSL n'est pas encore activé sur ton cluster / hébergement mutualisé. Il faut attendre quelques jours encore pour activer le SSL HTTPS.

çà marchera quand çà sera activé sur cluster003 (cf cette tache de travaux : http://travaux.ovh.net/?do=details&id=18027 )

Binano
20/05/2016, 14h31
Citation Envoyé par kingkurt
Il faut juste forcer le http par le .htaccess
style:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule ^ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Bonjour à tous,

j'ai remarqué ce problème sur les pages de mon forum phpbb référencées par Google également, j'ai essayé de trouver une solution sur le forum d'entraide suivant : http://forums.phpbb-fr.com/support-u...jet207835.html

mais rien n'y fait, tout ce qu'on m'a proposé ne fonctionne pas
La proposition de Kingkurt ne fonctionne pas non plus... Cependant lorsque je test les redirections sur http://www.redirection-web.net ça a l'air de fonctionner
Chrome / Firefox / IE = même problème, j'ai essayé de vider "historique de navigation", "cookies", "images et fichiers en cache" du navigateur mais ça bloque quand même...

Sinon je viens de tomber sur un truc en cherchant dans la FAQ OVH : http://help.ovh.ie/SslOnHosting
Si je ne veux pas utiliser le https:// il faut que ça renvoie sur cette adresse : https://ssl3.ovh.net/~LoginFTP ???

Pour moi ça donne https://ssl3.ovh.net/~binano mais comment faire ???

Je suis un peu perdu, si quelqu'un pouvait m'aider, merci.

vcasse
20/05/2016, 10h06
Citation Envoyé par Daniel60
Sur un 'bon' cluster j'ai pu mettre en place le ssl. Donc rectification de l'htaccess, et divers petits détails : robots.txt, sitemap, redirections. Pas de problème, ça tourne.
Par contre pour la désactivation, je préférais qu'elle se fasse par domaine dans la cas des multisites. Est-ce possible ?
J'ai noté que le port https est le 443. Ok ?
A terme, il sera possible de jouer avec les multisite pour définir lequel a le SSL actif ou non.
Dans un premier temps, le choix sera plus binaire : Activé / Pas activé.

Mais c'est dans nos tablettes

Ludo.H
20/05/2016, 09h18
Bonjour,

Il n' y a plus de geocache, il est désactivé depuis 1-2 mois maintenant, des bugs et vieux il ne pouvait supporté tout ce que nous mettons en place en ce moment.
Il sera remplacer par le nouveau CDN, qui se déploie petit à petit.

Le HTTPS sera actif par défaut sur l'IP du cluster, mais pour le moment non fonctionnel sur CDN ou pour ceux qui ont déjà un certificat payant.
Dans ce dernier cas (certificat payant) il faut garder l'IP du hostedssl dans sa zone DNS.

Pour le HTTPS en effet le port par défaut est bien le 443.

Cdt,

buddy
19/05/2016, 19h31
ok. ce que je ne comprend pas, c'est que pourtant ce genre d'ip correspond à 3 PoP (Basic) donc logiquement avec Geocache.

Enfin, pas grave, OVH clarifiera ceci plus tard surement.

Daniel60
19/05/2016, 18h54
Pas de geocache genre 213.186.xxx.xx

buddy
19/05/2016, 18h18
Je pense que çà se limitera comme actuellement à supprimer le certificat, pas à bloquer le port 443 (le port HTTPS par défaut).

Tiens, puisque chez toi çà marche, petite question, sur ton site qui va bien, tu as quelle ip ?
une ip qui est dans la colonne "sans géocache" ? https://www.ovh.com/fr/g1290.geocache
un ips de la colonne 3 POP ?
une ip de la colonne 17 pop ?

Daniel60
19/05/2016, 18h09
Citation Envoyé par buddy
Sur la maillling list Web, la possibilité de désactivation du SSL a été annoncé sous 10 jours le 13 mai @18h.

Donc je pense que çà sera pour la semaine prochaine et pas avant
Sur un 'bon' cluster j'ai pu mettre en place le ssl. Donc rectification de l'htaccess, et divers petits détails : robots.txt, sitemap, redirections. Pas de problème, ça tourne.
Par contre pour la désactivation, je préférais qu'elle se fasse par domaine dans la cas des multisites. Est-ce possible ?
J'ai noté que le port https est le 443. Ok ?

kingkurt
19/05/2016, 17h16
Citation Envoyé par Fredo-73
Sage décision. Ca me va ... ;-)
Sage oui ! Mais y a t-il une date prévisible ? Pour le moment ça l'air de ne pas avancer du tout

Fredo-73
19/05/2016, 16h21
Citation Envoyé par vcasse
Nous avons préféré fixer ces quelques anomalies et ne pas risque de coupure globale du cluster sur Internet.
Sage décision. Ca me va ... ;-)

vcasse
19/05/2016, 10h18
Bonjour à tous,

Effectivement, le déploiement ne va pas aussi vite que nous le souhaiterions. Mais nos tests de début de semaine ont révélés quelques anomalies sur les IPlb des clusters restant à déployer. Nous avons préféré fixer ces quelques anomalies et ne pas risque de coupure globale du cluster sur Internet.

La tâche travaux continue d'être mise à jour.

Cordialement,
Vincent

kingkurt
18/05/2016, 17h59
Ca serais déjà bien que l'https marchera sur tout les clusters. Ca n'as pas l'air d'avancer vite

buddy
18/05/2016, 17h22
Sur la maillling list Web, la possibilité de désactivation du SSL a été annoncé sous 10 jours le 13 mai @18h.

Donc je pense que çà sera pour la semaine prochaine et pas avant

nextgen2
18/05/2016, 16h14
On en sommes nous concernant la possibilité de désactiver le SSL ?

Jikoo
17/05/2016, 21h18
Citation Envoyé par Abazada
Du passé ? XP représentait encore en février 1 PC sur 8 !...
http://www.developpez.com/actu/96668...incontestable/
Citation Envoyé par JBGO
Ce qui est très inquiétant en 2016 ....
Bah, ça ne m'étonne pas.
Voici ce que je note:
1) La plupart des PC sous XP sont installés sans licence avec un simple CD 700 Mo.
2) Ces gens ont un vieux PC (environ + de 5 ans) et ne veulent/peuvent pas migrer (car PC trop lent, par exemple)
3) Aussi, beaucoup de bots (et requêtes cURL) envoient cet user-agent et cet OS.
4) XP a le plus gros réservoir de logiciels... d'ailleurs, pas forcément compatible avec les OS récents.
5) En 2016, la plupart des logiciels utilisés fonctionnent encore sur cet OS (LibreOffice, Firefox, VLC, ccleaner, notepad++...)
6) Pas besoin de perdre son temps avec des mises à jour hasardeuses et longues (cf. win8 et win10)
7) Le plus simple des OS Windows en terme d'utilisation.

Bref, désolé, je me suis écarté du sujet initial !

JBGO
14/05/2016, 20h47
Citation Envoyé par jonathanpatate
Petite question en passant, sur mon site (perso2014 : cluster007 : 213.186.33.18) j'ai droit à ce message sur Chrome/Firefox :
SSL_ERROR_BAD_CERT_DOMAIN (Mauvais site).
Le certificat est au nom de nhysi.com.
Normal ?
Même problème pour un ami sur un de ses sous-domaines (cluster007)

http://img15.hostingpics.net/pics/90...urecluster.jpg

Citation Envoyé par Abazada
Du passé ? XP représentait encore en février 1 PC sur 8 !...
Ce qui est très inquiétant en 2016 ....

jonathanpatate
14/05/2016, 20h26
Petite question en passant, sur mon site (perso2014 : cluster007 : 213.186.33.18) j'ai droit à ce message sur Chrome/Firefox :
SSL_ERROR_BAD_CERT_DOMAIN (Mauvais site).
Le certificat est au nom de nhysi.com.
Normal ?

kingkurt
14/05/2016, 12h30
Citation Envoyé par Daniel60
Mais XP+IE8 c'est plutôt rare.
C'est vrai ! Sur mes sites XP+IE8 est à <0,2%

Daniel60
14/05/2016, 08h18
Citation Envoyé par Abazada
Du passé ? XP représentait encore en février 1 PC sur 8 !...
Mais XP+IE8 c'est plutôt rare.

Abazada
14/05/2016, 03h30
Citation Envoyé par JBGO
Après XP et ie8, c'est du passé ...
Du passé ? XP représentait encore en février 1 PC sur 8 !...
http://www.developpez.com/actu/96668...incontestable/

Citation Envoyé par vcasse
Nous allons ajouter la semaine prochaine la possibilité de supprimer le certificat SSL (puis de le réactiver plus tard) si besoin.
Parfait & Merci

JBGO
13/05/2016, 19h18
Citation Envoyé par Gaston_Phone
Non, je suis sur le cluster010.
Alors que dois-je faire ?
Pour l'instant, rien, ton cluster sera traité la semaine prochaine d'après les infos d'ici : http://travaux.ovh.com/?do=details&id=18027

nitrix-ud
13/05/2016, 19h13
Citation Envoyé par Gaston_Phone
Chez moi, cela ne fonctionne pas.
J'ai toujours le message "La connexion n'est pas sécurisée".
JBGO a raison, pb de certificat...

Le navigateur avant toute chose vérifie le certificat... d'où le message d'erreur

Le fait de forcer le http avec le htaccess ne marche qu'avec un certificat qui marche...

- - - Mise à jour - - -

Non, je suis sur le cluster010.
Alors que dois-je faire ?
tu ne dois rien faire, pour l'instant tu n'es pas impacté, tu peux toujours laisser ton htaccess comme il est...

Gaston_Phone
13/05/2016, 19h11
Citation Envoyé par JBGO
Plutôt un problème de certificat dans ce cas, t'es bien sur le bon cluster (les 4 listés) ? Sinon faut regarder le détail du certificat pour voir si certificat est bien généré pour le bon domaine
Non, je suis sur le cluster010.
Alors que dois-je faire ?

JBGO
13/05/2016, 19h00
Citation Envoyé par buddy
Xp et les certificats letsencrypt ça ne fait pas bon ménage...
Ils ont sorti un fix it début avril je crois. Mais je ne sais pas si les certificats ovh ont le fix it letsencrypt Xp.

C'est compatible depuis la X3 (début avril), mais ça dépend du cipher utilisé

Citation Envoyé par nitrix-ud
ouais... c'est du passé pour nous, mais pour pas mal de mes clients XP et ie8, c'est encore du présent !!
et idem pour Java

Let's encrypt est pourtant compatible java non ?
De même, ça dépend du / des ciphers, c'est les longues chaines visible sur ssllabs ex: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"

- - - Mise à jour - - -

Citation Envoyé par Gaston_Phone
Chez moi, cela ne fonctionne pas.
J'ai toujours le message "La connexion n'est pas sécurisée".
Plutôt un problème de certificat dans ce cas, t'es bien sur le bon cluster (les 4 listés) ? Sinon faut regarder le détail du certificat pour voir si certificat est bien généré pour le bon domaine

Gaston_Phone
13/05/2016, 18h58
Citation Envoyé par nitrix-ud
Il faut juste forcer le http par le .htaccess
style:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule ^ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Merci @kingkurt, ça marche nickel
Chez moi, cela ne fonctionne pas.
J'ai toujours le message "La connexion n'est pas sécurisée".

buddy
13/05/2016, 18h40
Xp et les certificats letsencrypt ça ne fait pas bon ménage...
Ils ont sorti un fix it début avril je crois. Mais je ne sais pas si les certificats ovh ont le fix it letsencrypt Xp.

nitrix-ud
13/05/2016, 18h38
Après XP et ie8, c'est du passé ... pour Java 8, c'est un plus problématique dans certains cas par contre
ouais... c'est du passé pour nous, mais pour pas mal de mes clients XP et ie8, c'est encore du présent !!
et idem pour Java

Let's encrypt est pourtant compatible java non ?

JBGO
13/05/2016, 18h04
Citation Envoyé par nitrix-ud
j'obtiens A

par contre j'ai pas mal de handshake_failure

Android 2.3.7 No SNI 2 Server sent fatal alert: handshake_failure
IE 6 / XP No FS 1 No SNI 2 Server closed connection
IE 8 / XP No FS 1 No SNI 2 Server sent fatal alert: handshake_failure
Java 6u45 No SNI 2 Server sent fatal alert: handshake_failure
Java 7u25 Server sent fatal alert: handshake_failure
Java 8u31 Server sent fatal alert: handshake_failure
OpenSSL 0.9.8y Server sent fatal alert: handshake_failure

En particulier, ça veut dire que java ne marcherait pas en https ?
et qu'un XP avec ie8 non plus ?
Ca dépend du cipher qui a été utilisé par OVH

Après XP et ie8, c'est du passé ... pour Java 8, c'est un plus problématique dans certains cas par contre

nitrix-ud
13/05/2016, 17h51
Je me suis mal exprimé Les certificats seront regenérés, seulement si ils existent encore (si pas de suppression en opt-out).
j'avais bien compris

merci Vincent et Buddy pour vos réponses,
je vais donc me retrousser les manches et partir sur la 2) je pense

vcasse
13/05/2016, 17h47
Citation Envoyé par nitrix-ud
oui j'ai vu que l'expiration est rapide, je serais curieux de savoir combien de gens vont supprimer leur certificat

Je me suis mal exprimé Les certificats seront regenérés, seulement si ils existent encore (si pas de suppression en opt-out).

Citation Envoyé par nitrix-ud
Vincent, tu en penses quoi ? est-il est mieux de ?
1) supprimer le certificat
ou
2) garder le certificat et forcer le http en htaccess en attendant de migrer...

J'aime bien la deuxième solution (elle demande plus de boulot), car cela me parait plus facile de faire des tests...
je force le https, je force le http, ...
suffit de modifier le htaccess

Personnelement, je préfére l'option 2. Mais parfois, la modification d'un htaccess n'est pas le plus rassurant . Le htaccess a surtout un interêt si tu as la volonté de remettre rapidement le site en HTTPS et que tu veux switcher facilement pour les tests.

buddy
13/05/2016, 17h43
Letsencrypt te propose un cron qui renouvelle automatiquement sur les dédiés donc tu le gardes c'est transparent pour toi. (tout est faisable en ligne de commande création et renouvellement , donc tu le mets en cron et nickel. Testé et approuvé sur des dédiés)

Ta 2eme solution marche bien et t'éviteras plus tard de devoir te connecter au manager pour demander un certificat.

nitrix-ud
13/05/2016, 17h39
D'ailleurs, Let's encrypt impose un renouvellement des certificats tous les trois mois que nous prenons en charge. Donc ce sera noyé dans la masse.
oui j'ai vu que l'expiration est rapide, je serais curieux de savoir combien de gens vont supprimer leur certificat


Vincent, tu en penses quoi ? est-il est mieux de ?
1) supprimer le certificat
ou
2) garder le certificat et forcer le http en htaccess en attendant de migrer...

J'aime bien la deuxième solution (elle demande plus de boulot), car cela me parait plus facile de faire des tests...
je force le https, je force le http, ...
suffit de modifier le htaccess

nextgen2
13/05/2016, 17h39
merci de ta réponse chmod777

chmod777
13/05/2016, 17h37
Citation Envoyé par nextgen2
Oui j'ai vu mais en attendant que le CDN soit compatible c'est bon ?
De ce que j'en comprends, oui. Reste à savoir quand exactement ce sera mis en place.

vcasse
13/05/2016, 17h34
Citation Envoyé par nitrix-ud
Cela va dans le bon sens...

il n'est pas possible de simplement désactiver l'utilisation du SSL sans supprimer le certificat ?
(ça parait juste dommage de supprimer qq chose que vous avez généré...)
Non, mais il n'est pas difficile pour nous de le regénérer.
D'ailleurs, Let's encrypt impose un renouvellement des certificats tous les trois mois que nous prenons en charge. Donc ce sera noyé dans la masse.

Cordialement,
Vincent

raoul-h
13/05/2016, 17h33
Citation Envoyé par vcasse
Bonjour raoul-h

Nous avons bien conscience des ces soucis. Nous allons ajouter la semaine prochaine la possibilité de supprimer le certificat SSL
Très bien, merci pour ce retour Vincent, en effet ça va dans le bon sens.
C'est exactement ce que je compte faire : supprimer le SSL puis migrer peu à peu mes (nombreux) sites dans de bonnes conditions et lorsque j'aurai décidé de le faire.
Vivement la semaine prochaine alors

nitrix-ud
13/05/2016, 17h24
Nous avons bien conscience des ces soucis. Nous allons ajouter la semaine prochaine la possibilité de supprimer le certificat SSL (puis de le réactiver plus tard) si besoin. Nous terminons tout d'abord la génération et le déploiement du parc des hébergements web (on veut éviter de réactiver un certificat préalablement désactivé volontairement).
Cela va dans le bon sens...

il n'est pas possible de simplement désactiver l'utilisation du SSL sans supprimer le certificat ?
(ça parait juste dommage de supprimer qq chose que vous avez généré...)

vcasse
13/05/2016, 17h20
C'est un workaround qui fonctionne en attendant l'option de opt-out

nitrix-ud
13/05/2016, 17h18
Par curiosité si tu testés le ssl avec ce site https://www.ssllabs.com/ssltest/ sur ton site qui va bien tu obtiens quelle note ?
j'obtiens A

par contre j'ai pas mal de handshake_failure

Android 2.3.7 No SNI 2 Server sent fatal alert: handshake_failure
IE 6 / XP No FS 1 No SNI 2 Server closed connection
IE 8 / XP No FS 1 No SNI 2 Server sent fatal alert: handshake_failure
Java 6u45 No SNI 2 Server sent fatal alert: handshake_failure
Java 7u25 Server sent fatal alert: handshake_failure
Java 8u31 Server sent fatal alert: handshake_failure
OpenSSL 0.9.8y Server sent fatal alert: handshake_failure

En particulier, ça veut dire que java ne marcherait pas en https ?
et qu'un XP avec ie8 non plus ?

nextgen2
13/05/2016, 17h16
"Nous avons aussi dans les tuyaux le CDN compatible SSL. On a encore un peu de travail dessus avant de le proposer correctement, mais ça arrive aussi."
Oui j'ai vu mais en attendant que le CDN soit compatible c'est bon ?

vcasse
13/05/2016, 17h15
Bonjour raoul-h

Nous avons bien conscience des ces soucis. Nous allons ajouter la semaine prochaine la possibilité de supprimer le certificat SSL (puis de le réactiver plus tard) si besoin. Nous terminons tout d'abord la génération et le déploiement du parc des hébergements web (on veut éviter de réactiver un certificat préalablement désactivé volontairement).

Nous allons aussi communiquer auprés de l'ensemble des clients qui vont bénéficier du SSL d'activé, pour leur indiquer, et les informer des soucis possibles avec le SSL.

Cordialement,
Vincent

buddy
13/05/2016, 17h14
Citation Envoyé par raoul-h
Est-ce qu'on pourrait rester dans le sujet svp ?


Imaginons un forum avec plusieurs milliers de membres et des dizaines de milliers de topics et de messages.
Ce forum contient, comme beaucoup de forums, des milliers d'images hotlinkées (depuis des hébergeurs d'images par exemple qui proposent des liens en http).

Avec la solution proposée par OVH, Google va indexer par défaut les URL en httpS et envoyer par défaut les visiteurs de ce forum sur ces URL httpS. Chaque visiteur se verra afficher, selon son navigateur, un ou plusieurs messages d'erreur très anxiogènes, ou carrément des interstitiels l'informant que le site n'est pas sécurisé, puisqu'une partie du contenu n'est pas en httpS (à savoir les images hotlinkées).
.
Je te rassure, il y a déjà pas mal de forums en https avec des images http et aucun message d'erreur bloquant la navigation..
Tu as des informations comme quoi la page n'est pas entièrement sécurisée uniquement si tu cliques sur le cadenas (pour des images hotlinkees)

chmod777
13/05/2016, 17h07
Citation Envoyé par nextgen2
Si on a l'option CDN activée, le SSL ne peut pas être activé c'est bien ça ?

Du coup si on veut rester en http, sans risque pour Google et que le SSL ne nous intéresse pas, on peut laisser activé l'option CDN et c'est bon ?

Merci
"Nous avons aussi dans les tuyaux le CDN compatible SSL. On a encore un peu de travail dessus avant de le proposer correctement, mais ça arrive aussi."

nextgen2
13/05/2016, 17h04
Si on a l'option CDN activée, le SSL ne peut pas être activé c'est bien ça ?

Du coup si on veut rester en http, sans risque pour Google et que le SSL ne nous intéresse pas, on peut laisser activé l'option CDN et c'est bon ?

Merci

nitrix-ud
13/05/2016, 16h50
Est-ce qu'on pourrait rester dans le sujet svp ?
désolé pour la digression

Je suis entièrement d'accord avec toi raoul-h

la migration vers du https peut-être très complexe... et demande du temps.

exemple pour du wordpress :
https://css-tricks.com/moving-to-https-on-wordpress/

Quand on a des centaines de sites, on fait comment ?
on fait ça du jour au lendemain ?

Perso, je vais forcer le http avec le htaccess et migrer tranquillement...

ou encore mieux :
Pour être constructif : je pense qu'il faut implémenter un opt-in (ou, au pire, un opt-out) pour laisser le choix à chaque webmaster.

raoul-h
13/05/2016, 16h30
Est-ce qu'on pourrait rester dans le sujet svp ?

Je vais donner un exemple concret pour que tout le monde comprenne bien l'enjeu.

Imaginons un forum avec plusieurs milliers de membres et des dizaines de milliers de topics et de messages.
Ce forum contient, comme beaucoup de forums, des milliers d'images hotlinkées (depuis des hébergeurs d'images par exemple qui proposent des liens en http).

Avec la solution proposée par OVH, Google va indexer par défaut les URL en httpS et envoyer par défaut les visiteurs de ce forum sur ces URL httpS. Chaque visiteur se verra afficher, selon son navigateur, un ou plusieurs messages d'erreur très anxiogènes, ou carrément des interstitiels l'informant que le site n'est pas sécurisé, puisqu'une partie du contenu n'est pas en httpS (à savoir les images hotlinkées).

La plupart des visiteurs en provenance de Google vont fuir (= perte de revenus pour l'éditeur), le pogo-sticking va exploser (le visiteur retourne sur Google) et le référencement du site va s'écrouler en quelques semaines (= perte de revenus durable et significative pour l'éditeur).

Pour certains sites, certains artisans et certains e-commerçants les conséquences vont être cataclysmiques, OVH est en train de poignarder ses clients dans le dos !

Ensuite, sur le principe, je pense qu'un hébergeur digne de ce nom doit rester neutre et n'a pas à imposer à ses clients ses points de vue sur le web ou sur la sécurité. Qu'OVH propose la possibilité de faire du SSL, je trouve ça très bien, et ça ne me dérange pas de payer pour, même si je n'en ai aucune utilité, mais en revanche il faut que ça reste un choix, et que chaque webmaster puisse l'implémenter comme il l'entend et surtout QUAND il l'entend. Les migrations http -> https sont extrêmement complexes à gérer sur certains sites, il y a beaucoup de cas particuliers, et beaucoup se sont cassé les dents sur ces migrations depuis que Google a commencé son évangélisation à ce sujet.

Tout ça part d'une très bonne intention, mais n'oublions jamais que l'enfer est pavé de bonnes intentions. Ici, je trouve qu'OVH sort de son rôle et de sa neutralité d'hébergeur et fait une grosse erreur, ça va poser beaucoup de problèmes, et le support va être inondé dès que Google commencera à indexer les mauvaises URL de sites qui tournent sans broncher et sans problème depuis des années.

Pour être constructif : je pense qu'il faut implémenter un opt-in (ou, au pire, un opt-out) pour laisser le choix à chaque webmaster.

buddy
13/05/2016, 16h25
Aucune idée. La doc d ovh ne doit pas être claire car sur le lien précédant il y a bien écrit que c'est 3 pop avec ces ips.

Par curiosité si tu testés le ssl avec ce site https://www.ssllabs.com/ssltest/ sur ton site qui va bien tu obtiens quelle note ?

nitrix-ud
13/05/2016, 16h15
Avec les ips 213.186. 33.x tu as obligatoirement le CDN..
Soit sur 3 pop soit sur 17. Ou alors je n'ai pas compris.. (ce qui est possible)
En tout cas, j'ai bien comme ip 213.186.33.24 dans les Zones DNS
et CDN désactivé dans la vue multi-site de l'hébergement...

Et le seul site qui marche pour moi pour l'instant est un site sur un hébergement perso2014 sur le cluster013 avec pour ip : 213.186.33.24

ou alors je n'ai pas compris

buddy
13/05/2016, 16h09
Avec les ips 213.186. 33.x tu as obligatoirement le CDN..
Soit sur 3 pop soit sur 17. Ou alors je n'ai pas compris.. (ce qui est possible)

nitrix-ud
13/05/2016, 16h07
Apparemment ça ne marche que pour le site sans CDN.
Donc ça nearche que pour les sites qui ont une ip en 37.187.184.x
Moi le seul site qui marche est sur 213.186.33.18 (cluster013), sans l'option CDN
j'ai un multi-site sans CDN sur le cluster013 et ça ne marche pas

- - - Mise à jour - - -

Il ne fait aucun doute qu'on passera tous au https...

La grande majorité des sites n'est donc pas concernée
(pas de membres/clients, donc pas de login, de password)
et ça semble en effet une mauvaise idée de prendre le risque de les "casser"
en imposant un accès HTTPS.
mais je suis d'accord avec toi Abazada

Abazada
13/05/2016, 15h58
Citation Envoyé par chmod777
De toute façon, les navigateurs afficheront bientôt un cadenas rouge sur toutes les pages servies en http et affichant un champ de mot de passe, ce qui n'est pas très vendeur. Donc autant passer au https.
La grande majorité des sites n'est donc pas concernée
(pas de membres/clients, donc pas de login, de password)
et ça semble en effet une mauvaise idée de prendre le risque de les "casser"
en imposant un accès HTTPS.

buddy
13/05/2016, 15h50
Citation Envoyé par nitrix-ud
@Ludovic,

C'est sensé marcher sur ces 4 clusters :
cluster012 (1000gp)
cluster013 (20gp)
cluster002 (90plan)
cluster007 (xxlplan)
??

De mon côté, ça marche sur un site... sur les autres erreur de certificat ...
Apparemment ça ne marche que pour le site sans CDN.
Donc ça nearche que pour les sites qui ont une ip en 37.187.184.x cf https://www.ovh.com/fr/g1290.geocache https://www.ovh.com/fr/g1290.geocache

Si tu modifiés ton ip pour le ssl compte 6 bonnes heures pour la propagation..

nitrix-ud
13/05/2016, 15h10
Il faut juste forcer le http par le .htaccess
style:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule ^ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Merci @kingkurt, ça marche nickel


Forcer le SSL par défaut va déclencher des millions de messages d'erreurs sur des dizaines de milliers de sites, pour tous les visiteurs en provenance de Google et sur tous les sites dont les webmasters ne sont pas sur ce forum ni sur les mailing lists (c-à-d 99,9% des clients d'OVH).
c'est clair...

raoul-h
13/05/2016, 15h09
Citation Envoyé par Ludo.H
Dans le cas où une page est, à la fois, accessible via une URL en HTTP et en HTTPS, le moteur de Mountain View choisira d’indexer la version sécurisée
Ludovic, c'est exactement ce que j'écris dans mon premier message.
La question qui se pose est la suivante : Est-ce que le rôle d'un hébergeur est de forcer la main à un webmaster et de ne pas lui laisser le choix face à deux technos ? Est-ce le rôle d'un hébergeur d'évangéliser ses clients ? Est-ce que moi, webmaster, j'ai le droit de choisir la techno de mon choix pour mes sites, SANS AVOIR A ME JUSTIFIER ?

Forcer le SSL par défaut va déclencher des millions de messages d'erreurs sur des dizaines de milliers de sites, pour tous les visiteurs en provenance de Google et sur tous les sites dont les webmasters ne sont pas sur ce forum ni sur les mailing lists (c-à-d 99,9% des clients d'OVH).

kingkurt
13/05/2016, 15h05
Citation Envoyé par nitrix-ud
C'est sensé marcher sur ces 4 clusters :
cluster012 (1000gp)
cluster013 (20gp)
cluster002 (90plan)
cluster007 (xxlplan)
Et pour le cluster014 ça sera pour quand ?
Désolé j'ai hâte de tester un de mes sites en https

nitrix-ud
13/05/2016, 14h58
@Ludovic,

C'est sensé marcher sur ces 4 clusters :
cluster012 (1000gp)
cluster013 (20gp)
cluster002 (90plan)
cluster007 (xxlplan)
??

De mon côté, ça marche sur un site... sur les autres erreur de certificat ...

Daniel60
13/05/2016, 14h30
Concernant les liens externes en http ce n'est très méchant sur Firefox : un triangle jaune vient se superposer au cadenas.

Ludo.H
13/05/2016, 14h27
Bonjour,

Les conditions de l’indexation par google.

Dans le cas où une page est, à la fois, accessible via une URL en HTTP et en HTTPS, le moteur de Mountain View choisira d’indexer la version sécurisée même si sa popularité est nulle (n’ayant aucun lien externe pointant vers elle). Mais elle devra respecter de nombreuses conditions, dont quelques unes sont listées ci-dessous :

  • Si un fichier robots.txt ou une balise meta “noindex” ne bloquent pas son indexation
  • Si elle ne redirige pas l’internaute vers une page non sécurisée (HTTP)
  • Si le lien « rel= »canonical »” ne pointe page vers la page HTTP
  • Si le sitemap ne liste pas la page en version HTTP


Pour conclure, Google met en avant le désir de sécuriser Internet et de protéger les internautes contre l’injection de contenu sur une site web avec une connexion non sécurisée.

Les gains

  • cela renforce la confiance des internautes envers votre site et votre entreprise (si c'est votre cas). Dans le cas d'un site ecommerce, c'est un point majeur, un argument que vous pourrez d'ailleurs utiliser dans votre stratégie marketing. Pour les autres cas, c'est toujours bon de renforcer votre crédibilité, c'est un facteur positif pour accroître votre notoriété.
  • c'est un avantage en référencement naturel sur Google


Le future

HTTP/2 : il n'a pas forcement besoin de chiffrement, cependant les navigateurs (firefox, chrome, Opera, IE, Edge) ont statués sur l'utilisation unique de HTTP/2 avec TLS. (source : https://en.wikipedia.org/wiki/HTTP/2)
Il faudra des certificats pour faire du HTTP/2 .

JBGO
13/05/2016, 14h17
@chmod777 exactement

http://www.zdnet.com/article/google-...-sites-as-bad/

chmod777
13/05/2016, 14h14
De toute façon, les navigateurs afficheront bientôt un cadenas rouge sur toutes les pages servies en http et affichant un champ de mot de passe, ce qui n'est pas très vendeur. Donc autant passer au https.

raoul-h
13/05/2016, 14h11
@Daniel60, idéalement il faudrait de l'activable mais le désactivable me conviendrait aussi, ce serait le minimum

JBGO
13/05/2016, 14h07
OVH propose de mettre à jour leur infrastructure gratuitement pour générer les certificats et ça rale encore. On croit rêver.

Un webmaster sérieux va tout simplement ajouter dans son .htaccess une redirection https => http en redirection permanente et terminé.

Si le webmaster est encore plus sérieux et soucieux de ses visiteurs / clients, il modifie les quelques liens http en https et il fait la redirection inverse.

Raler pour raler ...

Daniel60
13/05/2016, 14h06
En ce qui me concerne je pencherais plutôt pour option désactivable.

raoul-h
13/05/2016, 14h01
@Gaston_Phone, justement, c'est en train d'être déployé, et le problème c'est que c'est déployé par défaut pour tout le monde et cela va générer d'énormes problèmes pour Google, pour les utilisateurs, pour les entreprises et pour les webmasters.

Il faut que le SSL reste une option activable, et non une implémentation par défaut !

chmod777
13/05/2016, 13h52
Salut,

Effectivement, il va y avoir du Mixed Content pour ceux qui ont défini des liens absolus http:// et non https:// voire juste ://
Après, il est théoriquement possible (d'après ce que j'ai compris) de demander au navigateur d'élever une requête http à https pour un même site en mettant ceci dans le .htaccess :
Header set Content-Security-Policy "upgrade-insecure-requests"
https://www.w3.org/TR/upgrade-insecure-requests/

Pas pu tester encore, et ce n'est pas implémenté sur Edge et Intermerd Explorer.

Daniel60
13/05/2016, 13h50
Citation Envoyé par Gaston_Phone
A une certaine époque OVH avait parlé de fournir gratuitement des certificats Let’s Encrypt pour les hébergements mutualisés PERSO.
Où en est-on ?
On en est là :http://travaux.ovh.net/?do=details&id=18027

Gaston_Phone
13/05/2016, 13h45
A une certaine époque OVH avait parlé de fournir gratuitement des certificats Let’s Encrypt pour les hébergements mutualisés PERSO.
Où en est-on ?

- - - Mise à jour - - -

Extrait du 22 décembre 2015 --> OVH s’engage auprès de Let’s Encrypt pour la fourniture gratuite de certificats SSL

kingkurt
13/05/2016, 13h17
Il faut juste forcer le http par le .htaccess
style:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule ^ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

raoul-h
13/05/2016, 13h00
Bonjour, je viens de voir ici qu'OVH était en train de déployer un certificat SSL sur tous les sites du mutu, par défaut.
Cela signifie que tous les sites hébergés sur le mutu seront accessibles via https (en plus de l'accès standard http).

C'est une énorme erreur de la part d'OVH.

En effet, depuis quelques mois, les robots de Google (GoogleBot) essayent, pour toutes les URL en http présentes dans l'index, de tester si une URL en https existe.

Si cette URL en https existe, alors c'est celle-ci qui sera en priorité indexée et référencée. C'est donc l'URL https qui sera présentée aux internautes en provenance de Google, même si le webmaster ne l'a pas choisi et si le protocole https génère des erreurs et des messages d'alerte au niveau du navigateur du visiteur. Il suffit d'un appel à un script externe en http pour déclencher ces alertes très anxiogène, et je vous laisse imaginer la catastrophe en terme de référencement, de revenus et d'expérience utilisateur. Des milliers de webmasters vont voir leur chiffre d'affaire chuter.

Il s'agit d'une véritable atteinte à la neutralité du réseau puisqu'OVH met les webmasters devant le fait accompli, ça part d'une bonne intention mais c'est inacceptable.

Je demande un roll-back immédiat des clusters déjà concernés et la mise en place d'une solution en opt-in , permettant aux webmasters volontaires, et uniquement aux volontaires, de bénéficier de cette solution SSL.

Merci