se débarasser de HTTPS

  • Auteur de la discussion Auteur de la discussion WRC
  • Date de début Date de début
Nouveau WRInaute
Bonjour

J'ai un petit soucis qui devient pénible.

Mon site était hébergé chez un hébergeur fournissant un certificat SSL. Le nom de domaine était donc dans le style : https://nom.ext.

L'hébergeur a fermé, j'ai donc migré ailleurs (sur le petit espace fournit par OVH avec le nom de domaine, ce qui me suffit pour 7 pages statiques), et là, pas de certificat SSL. Le nom de domaine est donc désormais http://nom.ext.

Rien de compliqué donc, et pourtant, depuis je ne rencontre que des ennuis avec les divers moteurs de recherches et navigateurs !

Firefox par exemple bloque l'accès du clic depuis Google en disant :

« Attention : risque probable de sécurité
Firefox a détecté une menace de sécurité potentielle et n’a pas poursuivi vers … »

J'ai tenté plusieurs choses : via Google Search, suppression du domaine, et création de deux suffixes (http et https), mais quand je demande dans le suffixe https://nom.ext. sa désindexation, ça supprime tout, y compris http://nom.ext. J'ai donc annulé ma demande. Google reproche un duplicate content, j'ai donc mis un <link rel="canonical" href= http://…> dans chaque fichier html

Et dans le htaccess, j'ai renseigné
RewriteCond %{SERVER_PORT} 443
RewriteRule ^(.*)$ http://nom.ext/$1 [R,L]

Pourtant, j'ai toujours la même erreur… Est-ce que quelqu'un peut m'aider, c'est un site pour une amie qui doit se lancer en micro entreprise, et c'est un coup dur pour elle…

Merci beaucoup
Bonne journée
 
WRInaute impliqué
pas de certificat SSL
Ce qui est une mauvaise chose, on est en 2023, et particulièrement pour un professionnel, fût-il en micro-entreprise, ça ne fait pas sérieux, même s'il n'y a pas de vente associée.

L'hébergement de base chez OVH (avec certificat) est à 1,59 € HT / mois, soit 22,90 euros par an.

Firefox par exemple bloque l'accès du clic depuis Google en disant « Attention : risque probable de sécurité
Et c'est logique : Google fournit un lien HTTPS, et tu n'arrive pas sur une page sécurisée (ne serait-ce que celle de la redirection). Pour cette raison passer de HTTPS à HTTP est plus délicat que l'inverse. Il faudrait maintenir HTTPS au moins le temps que le redirection vers HTTP soit intégrée par les moteurs de recherche.

C'est pour ça qu'il vaudrait mieux prendre un certificat.


Sinon, pour répondre à la question, il n'est pas très pertinent de faire une Rewrite à partir du port dans ce cas. Tu veux filtrer le HTTPS, autant le faire directement, et non pas par un biais détourné :
Apache config:
RewriteCond %{HTTPS} on
RewriteRule ^(.*)$ http://example.com/$1


À noter que ça ne résoudra pas directement ton problème, qui est que Google a indexé la page HTTPS, et qu'il te faut attendre qu'il prenne en compte la redirection dans son index.

En vrai, prend un certificat.
 
Nouveau WRInaute
Merci à vous deux pour vos réponses.

J'étais justement en discussion avec un conseiller OVH sur leur chat, pour mettre en place le certificat, car cela fait des jours que je suivais la démarche et que rien ne se passait (je suis aussi pour rester en https).

Je bloquais à l'étape Certificat SSL En cours de création, la conseillère m'a fait activer quelque chose dans l'onglet Multisite (a coté du nom de domaine, les … puis modifier et cocher SSL). La personne m'a dit que normalement ça allait être bon dans quelques instants. À suivre donc.
 
Nouveau WRInaute
Depuis Bing, ça semble désormais bon,
Dans la console OVH
Certificat SSL Oui - LETSENCRYPT - DV

Reste à ce que Google active la suppression de demande de suppression, ça devrait donc être tout dans l'ordre dans quelques jours.

ps : j'ai donc supprimé la balise canonical, et rewritecond dans le htaccess.

Merci, bonne journée
 
WRInaute occasionnel
bon mais il ne suffit pas d'ecrire https ou http, il faut un certificat https valide, même dans l'intervalle ou tu vas transferer vers http. sinon, tes url https vont hurler et les browsers ne voudront pas les afficher
 
WRInaute occasionnel
ca sert a ca le https, tu peux pas aller contre autrement t'imagines le buzier si on pouvait certifier un site quelconque.
bonjour les arnaques sur le web (et ca suffit pas, trop de certificats sont delivres ala yourf, et les utilisateurs, même si leur brower hurle,
ils passent a travers pour mieux se faire manger leur carte bancaire)
 
WRInaute occasionnel
http c'est pas cher, un gros certificat https c'a coute cher
Hello artoflog,

SSL, or Secure Sockets Layer, was developed to keep data on the internet safe from digital eavesdroppers and cyber criminals. For nearly three decades (28 years, to be exact), SSL has played a pivotal role in protecting online communication. And since it was developed, a lot has changed. Here are 5 things you might not know about SSL.


1. Netscape Created SSL in the 1990s

In 1995, Netscape introduced the first public version of SSL, known as SSL 2.0. You might be wondering: If there was an SSL 2.0, was there an SSL 1.0? Yes, there was. Netscape originally created SSL 1.0 in response to the first-ever web browser, Mosaic 1.0. However, they didn’t release SSL 1.0 to the public because it had security vulnerabilities that needed to be worked out.


2. SSL is Now TLS

Although they’re commonly referred to as SSL certificates, they’re technically called Transport Security Layer (TLS) certificates these days. In response to growing security concerns, the industry moved to SSL 3.0 in 1996; despite this, there were still significant vulnerabilities. As a result, TLS 1.0 was introduced in 1999, followed by the evolution into TLS 1.1 in 2006, and later into TLS 1.2 in 2008. Then, in 2018, a more secure and faster version of TLS was released, TLS 1.3, which is currently supported by 64.8% of sites.


3. Every SSL Certificate Needs Two Keys

The SSL/TLS protocol relies on two keys: a public key and a private key. The public key, which is used for encryption, is included in the server’s SSL/TLS certificate and shared freely by the client. This key is used to encrypt data before transmitting it to the server. On the receiving end is the private key, which is stored by the server and used to decrypt data sent by the client. Once the data is encrypted with the public key, it can only be decrypted with the server’s private key, ensuring secure communication and authentication.


4. Some SSL/TLS Certificates Use Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy (PFS) in SSL/TLS ensures that cybercriminals can’t decrypt past or future session data. To enable PFS, the server and client use a one-time (ephemeral) key agreement method, ensuring the keys are only used for that session and never stored.

PFS uses either the Diffie-Hellman Ephemeral (DHE) or the Elliptic Curve Diffie-Helman Ephemeral (ECDHE) protocols, both of which offer more security than traditional RSA. Instead of relying only on the server’s private key for session encryption, DHE and ECDHE key exchanges require the server and client to independently calculate their key pairs using their piece of a shared value. So, even if a cybercriminal compromises the server’s private key, they won’t be able to use that key to decrypt past or future sessions.


5. There are Three Validation Levels

While all SSL certificates provide the same encryption, they come in three distinct validation levels for identity verification. And which certificate a business should choose largely depends on its requirements, budget, and compliance needs. For instance, a blogger might opt for a DV SSL certificate, whereas a larger e-commerce site handling payment information would likely choose an EV SSL certificate to establish the highest level of identity validation and boost user trust.

Now, let’s dive into the different validation levels:


Domain Validation (DV): This level of validation provides the lowest identity assurance but is ideal for websites needing basic encryption and nothing more. Since DV certificates offer basic identity validation, they are inexpensive and can be issued within minutes.



ca reste acceptable, juste pour 1 domain
1698079397324.png
 
WRInaute impliqué
http c'est pas cher, un gros certificat https c'a coute cher
HTTPS c'est juste du HTTP sur une communication sécurisée SSL/TLS. Il est nécessaire d'avoir un certificat pour chiffrer la communication mais il est possible d'en obtenir un gratuitement auprès de Let's encrypt, c'est d'ailleurs ce qui est très largement proposé (plus de la moitié des sites sont sécurisés par une transaction reposant sur un certificat de Let's encrypt).

Ça ne coûte littéralement rien si l'on souhaite une certification pour le seul besoin de TLS.
 
Nouveau WRInaute
Oui, comme dit Boostseo, Cloudflare est la solution, pour la sécurité (firewall et autres), un cdn et le ssl gratuit.

Il n'a pas vraiment de concurrent en ce moment, et tout site sérieux à intérêt à y mettre son site.

J'avais arrêté de l'utiliser, étant passer à Sucuri qui est très cher, mais une fois quitté Sucuri, je n'avais d'autres choix que de revenir à Cloudflare.
 
Discussions similaires
C
Réponses
4
Affichages
2K
christele2
C
Haut