Apache – Alles umleiten außer einem Pfad

Wer schon einmal eine Domain komplett z.b. auf https://domain.name umgeleitet hat, der kennt so einen Vhost Eintrag:

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    Redirect 301 / https://domain.name
</VirtualHost>

Was aber wenn man einen Pfad nicht umleiten kann/darf/will, weil das zu Problemen führen würde z.b. mit Lets Encrypt ?

Im Falle von Let’s Encrypt ist die Lösung ein negativer Pfadausschluß :

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    RedirectMatch 301 ^/((?!.well-known/acme-challenge).*)$ https://domain.name
</VirtualHost>

Damit wird alles, nur nicht der Pfad „/.well-kown/acme-challenge“ umgeleitet. Es ist für Lets Encrypt jetzt wieder möglich, die Challenges abzufragen.

Lets Encrypt: Zertifikatsprobleme auf iOS Geräten

Seit Dezember 2015 stellt Lets Encrypt kostenlose Zertifikate zur Verfügung. Damit kann man Webseiten und Mailserver schützen, wenn da nicht die liebe Realität in Form von iOS wäre.

Bei unserem hausinternen Versuch, die Mailserver von einem kommerziellen Comodozertifikat auf Lets Encrypt umzustellen, was für Webseiten überhaupt kein Problem war, stellte sich raus, das sofort alle iOS Endgeräte, egal ob iPhone 5,6,7 oder iOS 9,10 keine Emails mehr empfangen konnten. Entäuschenderweise war auch Thunderbird betroffen 🙁

Daraufhin haben wir auf ein Comodozertifikat umgestellt und die Lage beruhigte sich, bis einige iOS Geräte anfinden, nur noch Emails zu senden, aber keine mehr zu empfangen. Wohlgemerkt, mit dem gleichen SSL-Zertifikat 😉

Nach derzeitigen Erkenntnissen seitens Comodo und unseren Technikern, liegt das Problem beim iOS Gerät selbst. Mal sehen was Apple dazu meint.

Auflösung: Mail.APP ist buggy, denn jedes andere installierte Emailprogramm auf einem betroffenen IPhone hat das Zertifikat einwandfrei akzeptiert. Aber der Witz kommt jetzt, dem Kunden hat das neue Mailprogramm „My Mail“  viel besser gefallen als die original App 😀

 

Android 3.2 und das Let’s Encrypt Problem

Ich hab ja neulich auf HTTPS-Only Blog umgestellt, aber so ganz „Only“ geht es dann doch nicht.

Da die meisten RSS Feedleser für Handies die Zertifikate aus dem Truststore von Android benutzen, in dem Sie den internen Webbrowser benutzen um die Feeds anzuzeigen, kommt es mit Let’s Encrypt Zertifikaten zu Problemen: Die stehen da schlicht nicht drin. Wer da nicht drin steht, wird nicht angezeigt.

Das Problem habe ich bei meinen eigenen Android Programmen durch einen eigenen Truststore gelöst, der einfach die aktuellen Firefox Zertifikate bekommt. Das dieser Trick zwangsweise nur für eigene Programme funktioniert, mußte ich meinem Blog leider sagen, das Android weiterhin per Port 80 abrufen darf.

Und so geht so eine Ausnahme :

RewriteCond %{HTTP_HOST} .*marius\.bloggt-in-braunschweig\.de
RewriteCond %{SERVER_PORT}   !^443$
RewriteCond %{HTTP_USER_AGENT} !.*Android.3\.2.*
RewriteRule  (.*)  https://%{HTTP_HOST}/$1   [L]