[APACHE]redirect naar https en naar 'full server name'

[Kheos]

ok, op onze development webserver heb ik HTTPS aangezet en dit werkt perfect.
Het enige wat ik nu nog wil is redirecten zodat als users naar
http://servername.domein.com/login gaan, dit redirect naar https://servername.domein.com/login

Ook dat heb ik werkende gekregen met rewriterules.

Wat er dan nog misloopt is dat als users naar
http://servername/login gaan, ze de volgende certificate error krijgen:
ERR_CERT_COMMON_NAME_INVALID
Logisch, want mijn certificate gaat over servername.domein.com, niet over servername.


En daar beginnen de problemen:
Het lukt me met rewrite rules om het volgende te bereiken:

https + full server name: OK (want geen redirect nodig)
http + full server name: OK
http + servername: OK
https + full server name: niet ok (vreemd, want http->https werkt, en de combinatie https->https + servername - > full servername werkt, maar enkel servername - > full servername werkt niet? )

Na wat zoeken en vloeken lees ik dat het zou moeten werken met redirect rules, maar dat je eigenlijk beter met virtualhosts werkt. Ook goed, mar daar krijg ik het ook niet mee aan de praat.

Wat ik nu heb is:
https://servername.domein.com/login -> er gebeurt niks
https://servername.domein.com ->werkt, maar ik wil met /login)
http://servername.domein.com/login -> gaat naar https://servername.domein.com
https://servername -> certificate error
http://servername -> gaat naar https://servername.domein.com
...

Dit zijn mijn virtual hosts momenteel:
<VirtualHost *:80>
Redirect permanent / https://servername.domein.com%{REQUEST_URI}
</VirtualHost>

<VirtualHost *:443>
Redirect permanent / https://servername.domein.com%{REQUEST_URI}
...
hoop SSL geneuzel
...
</VirtualHost>

[Ploink]

Kheos schreef op vrijdag 12 december 2014 @ 10:41:

Dit zijn mijn virtual hosts momenteel:
<VirtualHost *:80>
Redirect permanent / https://servername.domein.com%{REQUEST_URI}
</VirtualHost>

<VirtualHost *:443>
Redirect permanent / https://servername.domein.com%{REQUEST_URI}
...
hoop SSL geneuzel
...
</VirtualHost>

Ik doe het zo:
edit: heb het ff aangepast met 2e https vhost.

code:

<VirtualHost *:80>
ServerName servername.domein.com
ServerAlias domein.com
ServerAlias servername
RedirectPermanent / https://servername.domein.com/
</VirtualHost>

<VirtualHost *:443>
ServerName servername.domein.com
# hoop SSL geneuzel
</VirtualHost>

<VirtualHost *:443>
ServerName domein.com
ServerAlias servername
RedirectPermanent / https://servername.domein.com/
# hoop SSL geneuzel
</VirtualHost>

Die %{REQUEST_URI} is dus niet nodig, apache plakt die er zelf al aan. Let wel op de trailing "/"
Bovendien moet je nooit redirecten naar zichzelf zoals je doet met die https.
Rewrite rules zijn niet nodig.

De 2e ssl vhost is om netjes te redirecten naar de eerste. Je krijgt waarschijnlijk nog steeds een certificaat error voor https://servername/ maar daar zou je eventueel een self-signed cert aan kunnen hangen. Sowieso kan die url alleen maar op het LAN en is die syntax sowieso niet netjes

[ Voor 41% gewijzigd door Ploink op 12-12-2014 11:27 ]

[Kheos]

Wel, ik had op een bepaald moment iets dergelijks (dus zonder die %{REQUEST_URI}) maar toen (en nu dus weer) kreeg ik het volgende:

https://servername.domein.com/login -> werkt (want geen redirect)
http://servername.domein.com/login -> gaat nu naar https://servername.domein.comlogin (dus zonder / tussen .com en login
Daarom dat ik die %{REQUEST_URI} begon te gebruiken in de hoop dat dat iets zou oplossen.

https://servername/login ->geeft nog steeds een certificate error ipv te redirecten en
http://servername/login ->redirect naar https://servername.domein.comlogin dus ook weer zonder /

[Ploink]

Kheos schreef op vrijdag 12 december 2014 @ 11:37:
http://servername/login ->redirect naar https://servername.domein.comlogin dus ook weer zonder /

Vandaar dus die trailing slash

RedirectPermanent / https://servername.domein.com[u][b]/[/b][/u]

[Kheos]

Ploink schreef op vrijdag 12 december 2014 @ 11:40:
[...]

Vandaar dus die trailing slash

RedirectPermanent / https://servername.domein.com[u][b]/[/b][/u]

fixed, thanks!

nu heb ik dus het volgende;
https://servername.domein.com/login -> OK
http://servername.domein.com/login -> OK
https://servername/login ->certificate error
http://servername/login ->OK

Eigenlijk zit ik nu terug in de situatie die ik met die rewrite rules had.

Ik snap nog steeds niet dat http://servername/login werkt en https://servername/login een certificate error geeft.
IMHO moeten ze beide lukken of beide falen.

Het is inderdaad een interne webserver en het https stuk werkt idd via een self-signed. Ik heb hier enkele omgevingen (development, staging, production) en ik had gehoopt op 1 certificaat per omgeving +1 voor applicationname.domein.com (die redirect al via dns naar productionserver.domain.com), maar nu zou ik dus 1 certificaat moeten aanvragen voor elke mogelijke situatie?

Dus
development-servername
development-servername.domein.com
staging-servername
staging-servername.domein.com
production-servername
production-servername.domein.com
applicationname.domein.com
applicationname

Dat is nog wel te behapstukken, maar als er later bijvoorbeeld een training-webserver bijkomt en/of iemand beslist dat development-applicationname en staging-applicationname ook maar moeten werken (en dus ook development-applicationname.domein.com en training-applicationname.domein.com en staging-applicationname.domain.com enzovoort) dan wordt ik daar niet vrolijk van en wil ik dat oplossen met wat slim redirecten.

[Ploink]

Kheos schreef op vrijdag 12 december 2014 @ 12:06:
[...]

Ik snap nog steeds niet dat http://servername/login werkt en https://servername/login een certificate error geeft.
IMHO moeten ze beide lukken of beide falen.

Het mechanisme is anders.

Als je naar http://servername/login gaat dan doet je browser een HTTP request. Deze is niet encrypted en er komt dus geen certificaat aan te pas. In de response staat een "301 Moved Permanently" met een verwijzing naar https://servername.domein.com/login, die je browser dan gaat opvragen.

Als je begint bij https://servername/login dan opent je browser een SSL verbinding met de server "servername" en stopt dan omdat het certificaat niet klopt. Dit gebeurt nog voordat het daadwerkelijke http request plaatsvindt die een redirect respons zou geven.

Als je toch een self-signed certificaat gebruikt, dan kun je een nieuwe maken die geldig is voor meerdere hosts. Als je servername toevoegt dan is dat probleem opgelost
http://apetec.com/support/GenerateSAN-CSR.htm
Gebruik dezelfde private key die je eerder gebruikte om te voorkomen dat je gebruikers het certificaat weer opnieuw moeten accepteren.

De beste manier is imho, om je luie gebruikers op te voeden dat ze de hele FQDN intypen zoals het hoort

[ Voor 4% gewijzigd door Ploink op 12-12-2014 14:45 ]

[Kheos]

die SAN ziet er inderdaad uit als een goeie oplossing

ohja, in jouw voorbeeld zet je in beide 443 virtual hosts "# hoop SSL geneuzel", maar dan moet je het dus ook op 2 plaatsen onderhouden en dit zou ik graag op 1 plaats houden. Geen idee of dat kan.

En mijn gebruikers opvoeden? De meeste zweven ergens tussen business en IT: lui genoeg om IT te zijn, maar business genoeg om er niks van te snappen.

[Donaldinho]

Kan je voor je teveel domeinen/certs niet gewoon een eigen CA opzetten en je users die als Root/Intermediate CA in hun browsers/keystores laten opvoeren?

Dan heb je in ieder geval geen brower/certificaat/ssl errors meer.

[Ploink]

Kheos schreef op vrijdag 12 december 2014 @ 16:28:
ohja, in jouw voorbeeld zet je in beide 443 virtual hosts "# hoop SSL geneuzel", maar dan moet je het dus ook op 2 plaatsen onderhouden en dit zou ik graag op 1 plaats houden. Geen idee of dat kan.

Veel van dat geneuzel kan idd eenmalig buiten de vhost config, behalve de "sslengine on" natuurlijk. Bij mij staat het in een aparte ssl.conf.

Overigens is de eerste vhost, dus ook de eerste ssl vhost, altijd de default. De vhost met de redirect kun je dus beter bovenaan zetten misschien.
Ik heb dit als eerste vhosts:

code:

<VirtualHost *:80>
    ServerName localhost.localdomain
    ServerAdmin nobody
    DocumentRoot /var/www/vhost/default
</VirtualHost>

<VirtualHost *:443>
    ServerName localhost.localdomain
    SSLEngine on
    SSLCertificateFile          /etc/pki/tls/certs/localhost.localdomain.pem
    SSLCertificateKeyFile       /etc/pki/tls/certs/localhost.localdomain.pem
    ServerAdmin nobody
    DocumentRoot /var/www/vhost/default
</VirtualHost>

Document root /var/www/vhost/default bestaat helemaal niet, resultaat "404 Not Found".
Dus, als je geen geldige hostname weet, dan ben je gewoon mijn server aan het scannen en dan mag je met dit kluitje daar het riet in

[_eXistenZ_]

Je hele plan gaat je niet lukken want voordat de rewrite in kan kicken wordt het certificaat al gecheckt en die is niet geldig dus werkt die hele rewrite niet. Wat Plons zegt dus.

Of effe bij RapidSSL een gratis certificaat binnenhengelen voor je forward-domeinen.

[ Voor 19% gewijzigd door _eXistenZ_ op 12-12-2014 20:01 ]