ubuntuusers.de

Hallo zusammen,

ich bereite derzeit einen VirtualHost für rein administrative/kritische Zwecke vor. Dies erfordert maximale Absicherung. In meinem Fall nutze ich Basic_Auth zusammen mit fail2ban, was auch bestens funktioniert. Damit Letsencrypt Zertifikate automatisch erneuert werden können, muss ich das dafür erforderliche Directory (.well-known) von Basic_Auth ausschließen. Dies mache ich wie folgt:

xx
xx
xx
<Directory "/var/www/subdomain.example.com/public_html">
    Options FollowSymLinks
    AllowOverride None
    # set an environtment variable "noauth" if the request starts with "/.well-known/"
    # This is needed for Letsencrypt certificates
    SetEnvIf Request_URI ^/.well-known/ noauth=1

    AuthType Basic
    AuthName "Restricted Content"
    AuthUserFile /ir/gend/wo/.htpasswd

    <RequireAny>
       Require env noauth
       Require env REDIRECT_noauth
       Require valid-user
    </RequireAny>

    SSLOptions +StdEnvVars
    DirectoryIndex index.html index.php
</Directory>
xx
xx
xx

Dies funktioniert weitgehend. Jetzt aber das Problem: Rufe ich die Subdomain im Browser auf, ohne etwas anzuhängen (subdomain.example.com/), so wird eine vorhandene index.html trotzdem ausgeliefert. Rufe ich hingegen "subdomain.example.com/index.html" auf, so wirkt Basic_Auth wie erwartet.

Kann mir jemand erklären, wie ich das verhindern kann?

tskv schrieb:

Damit Letsencrypt Zertifikate automatisch erneuert werden können, muss ich das dafür erforderliche Directory (.well-known) von Basic_Auth ausschließen.

Meines Erachtens wäre es sinnvoller, für .well-known ein Alias zu definieren, der ein ein anderes Verzeichnis zeigt. Beispielsweise so:

  DocumentRoot /var/www/subdomain.example.com/public_html

  Alias /.well-known /var/www/letsencrypt/.well-known

  <Directory "/var/www/letsencrypt/.well-known">
    Require all granted
  </Directory>

  <Directory "/var/www/subdomain.example.com/public_html">
    ...

Das müsstest du natürlich auch als Zielpfad für das Challenge konfigurieren.

Dies funktioniert weitgehend. Jetzt aber das Problem: Rufe ich die Subdomain im Browser auf, ohne etwas anzuhängen (subdomain.example.com/), so wird eine vorhandene index.html trotzdem ausgeliefert. Rufe ich hingegen "subdomain.example.com/index.html" auf, so wirkt Basic_Auth wie erwartet.

Das sollte normalerweise nicht auftreten. Was sagt

curl -i subdomain.example.com

curl liefert die Seite ebenfalls aus.

Die Freigabe für Letsencrypt funktioniert, wie sie soll. Die werde ich später ggf. weiter überarbeiten.

EDIT: Stop. Falsch. curl liefert die index.html des default Hosts. Also nicht die der Subdomain. Greife ich hingegen per ssl und curl auf die Subdomain zu, bekomme ich einen Auth Fehler, wie es sich gehört.

EDIT2: Nach einem Apache Restart (und mehreren Reloads) erscheint jetzt auch bei Aufruf der Subdomain das Anmelde-Form. Sowohl Firefox als auch Chromium hatten die Seite wohl noch im Cache. Nach Löschen klappt alles, wie es soll.

tskv schrieb:

EDIT: Stop. Falsch. curl liefert die index.html des default Hosts. Also nicht die der Subdomain. Greife ich hingegen per ssl und curl auf die Subdomain zu, bekomme ich einen Auth Fehler, wie es sich gehört.

Dann passt das ja.

Ja, ich bin erneut auf lokales Caching reingefallen. Ich Depp. Danke für die Hilfe.