web-dev-qa-db-fra.com

Servir le port 443 sur http crée 400 erreur de demande incorrecte au lieu de rediriger

Donc, pour la postérité, j'essaie de configurer mon serveur de sorte que même lorsque quelqu'un essaie d'aller sur http: // domain.com:443, il soit correctement redirigé vers la version https du site (https: // domain.com).

Lorsque vous testez quelque chose comme http: // domain.com:443, il ne redirige pas correctement vers https: // domain.com, je reçois à la place une page 400 Bad Request avec le contenu suivant:

Mauvaise Demande

Votre navigateur a envoyé une demande que ce serveur ne pouvait pas comprendre. Raison: vous parlez HTTP simple à un port de serveur compatible SSL. Utilisez plutôt le schéma HTTPS pour accéder à cette URL, s'il vous plaît.

Serveur Apache/2.4.18 (Ubuntu) sur sub.domain.com Port 443

J'ai essayé d'inclure les lignes suivantes dans mon 000-default.conf dans le <VirtualHost *:80>:

RewriteEngine On 
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

Mais ça n'a pas marché.

Ce problème se produit sur tous les domaines, sous-domaines et l'adresse IP du serveur lui-même.

Peut-être lié, essayer de faire un essai à blanc de letsencrypt renvoie les éléments suivants:

   Domain: domain.com
   Type:   connection
   Detail: Failed to connect to 123.123.123.123:443 for TLS-SNI-01
   challenge

Pour chaque domaine répertorié dans le dossier compatible avec les sites.

sslapache-2.4http
6
Bitz

TL; TR: vous ne pouvez pas servir à la fois HTTP et HTTPS sur le même port (443).

Bien qu'il soit en théorie possible de déterminer à partir des premières données du client si le client envoie une requête HTTP (c'est-à-dire GET .. ou similaire) ou démarre une prise de contact TLS (\x16\x03...) la plupart des serveurs Web ne le font pas. Au lieu de cela, ils s'attendent à ce que le client se comporte correctement, c'est-à-dire qu'il utilise du HTTP simple sur un port (généralement 80) et HTTPS sur un autre port (généralement 443).

Votre URL de http://example.com:443 oblige le navigateur à envoyer une requête HTTP simple au port 443. Mais le serveur attend TLS là-bas, ce qui signifie que votre requête HTTP ordinaire est inattendue. Apache est au moins assez agréable pour vérifier si les données entrantes pour une requête HTTP simple dans ce cas afin qu'il puisse vous offrir une description plus utile:

Raison: vous parlez en HTTP simple à un port de serveur compatible SSL. Utilisez plutôt le schéma HTTPS pour accéder à cette URL, s'il vous plaît.

Si vous essayez de telles demandes avec d'autres serveurs, ils fermeraient la connexion sans aucune erreur ou se bloqueraient simplement car ils espèrent toujours obtenir une prise de contact TLS avec le client.

10
Steffen Ullrich

J'ai eu cette même erreur et le coupable était que ma configuration essayait d'activer SSL sur mon port non SSL. Toute adresse de site Web commençant par http:// sera acheminé via le port 80 (<VirtualHost *:80>) et que l'hôte ne veut rien savoir de SSL. Tous les sites commençant par https:// sera acheminé via le port 443 (<VirtualHost *:443>)

Le problème le plus direct était que j'avais les détails SSL suivants sous mon *:80 Hôte, qui faisait qu'Apache essayait d'activer SSL pour une connexion non SSL.

SSLEngine on
SSLCertificateFile /bla.crt
SSLCertificateKeyFile /bla.key
SSLCertificateChainFile /bla.crt

Après avoir supprimé ces lignes de *:80 (et en s'assurant qu'ils étaient présents sous <VirtualHost *:443>) Mon serveur a refait surface.

Alors, voici mon <VirtualHost>s (tous dans /etc/Apache2/sites-available/http.conf mais peut être différent selon votre configuration):

<VirtualHost *:80>

    -- snip --

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_Host}%{REQUEST_URI} [R,L]

</VirtualHost>


<VirtualHost *:443>

    -- snip --

    SSLEngine on
    SSLCertificateFile /var/www/ssl/STAR_iconcierge_net_au.crt
    SSLCertificateKeyFile /var/www/ssl/STAR_iconcierge_net_au.key
    SSLCertificateChainFile /var/www/ssl/STAR_iconcierge_net_au.crt

</VirtualHost>

Remarquez comment *:80 (http) applique une réécriture à *:443 (https), qui applique ensuite SSL avec le SSLEngine on directive.

3
Abraham Brookes

Ce que vous cherchez en fait, c'est de renvoyer les en-têtes HSTS du serveur Web aux utilisateurs, qui indiquent au navigateur de toujours accéder au site à l'aide de TLS. Il n'y a pas de 301 la redirection se produit là-bas, comme vous pouvez le voir dans les outils de développement de n'importe quel navigateur.

Cela se produit avec Google par exemple. Une fois que vous avez visité Google pour la première fois, il vous a envoyé un en-tête HSTS et votre navigateur l'a enregistré dans une liste. Après, lorsque vous essayez de vous connecter à google.com avec http://, le navigateur modifie automatiquement la méthode de connexion en https:// sans aucune communication avec le serveur Web distant.

Il s'agit d'un autre mécanisme de sécurité pour empêcher les attaques contre la couche de sécurité.

2
Tero Kilkanen

Rien qui se trouve à l'intérieur du <VirtualHost *:80> la section sera traitée lorsque vous accéderez au site en utilisant le port 443.

Testez l'activation de la version ssl du site par défaut fourni avec Apache2 et essayez cette configuration à l'intérieur de <VirtualHost *:443>

0
canciobello