Symlinks in Linux - Verständnisproblem

[Raketenwilli]

Es gibt defacto keinen (jedenfalls nicht für das SSL-Zertifikat) Aufruf von subdomain.example.org, weil per .htaccess immer daraus https://example.org/subdomain/ gemacht wird.

Äh. Nein. Ich zeig Dir mal GENAU das:

RewriteCond %{HTTP_HOST} !^www\.fastix\.org
RewriteRule ^(.*)$  https://www.fastix.org/$1 [R=permanent,L]

• Das Zertifikat ist für www.fastix.org und für fastix.org gültig.

Ok? Run:

wget -d https://fastix.org
DEBUG output created by Wget 1.21.2 on linux-gnu.

Reading HSTS entries from /home/fastix/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2022-08-25 16:49:43--  https://fastix.org/
Auflösen des Hostnamens fastix.org (fastix.org) … 81.28.228.47
Caching fastix.org => 81.28.228.47
Verbindungsaufbau zu fastix.org (fastix.org)|81.28.228.47|:443 … verbunden.
Created socket 3.
Releasing 0x00000055a33833f0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00000055a3385120
certificate:
  subject: CN=fastix.org
  issuer:  CN=R3,O=Let's Encrypt,C=US
X509 certificate successfully verified and matches host fastix.org

---request begin---
GET / HTTP/1.1
Host: fastix.org
User-Agent: Wget/1.21.2
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
---response begin---
HTTP/1.1 301 Moved Permanently
Date: Thu, 25 Aug 2022 14:49:43 GMT
Server: Apache
Location: https://www.fastix.org/

Die Übertragung des Request-Headers und die Weiterleitung per Antwort-Header erfolgen nach der Überprüfung des Zertifikats. Warum zum Teufel sollte denn der Browser einem womöglich gefakten Server die Weiterleitungsadresse glauben - den Inhalt einer Webseite hingegen nicht?

1. Vor der Übertragung des Hostnames findet eine Grundverschlüsselung statt, bei der Zertifikate erst mal keine Rolle spielen.
2. Dann wird unter Angabe des Hostnamens nach dem Zertifikat gefragt.
3. Wenn das Zertifikat korrekt und korrekt beglaubigt ist erfolgt das Senden des Request Headers.

Wäre es anders, wüsste der Server auf der IP 81.28.228.47 nicht, welches der zig Zertifikate (da sind viele Webauftritte drauf...) er vorweisen soll.

Versuch mit ungültigem Hostname:

~> echo 81.28.228.47 foo.fastix.org | sudo tee -a /etc/hosts
81.28.228.47 foo.fastix.org

Und dann ...

tmp$ wget -d https://foo.fastix.org
DEBUG output created by Wget 1.21.2 on linux-gnu.

Reading HSTS entries from /home/fastix/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2022-08-25 17:05:19--  https://foo.fastix.org/
Auflösen des Hostnamens foo.fastix.org (foo.fastix.org) … 81.28.228.47
Caching foo.fastix.org => 81.28.228.47
Verbindungsaufbau zu foo.fastix.org (foo.fastix.org)|81.28.228.47|:443 … verbunden.
Created socket 3.
Releasing 0x00000055a7ae72c0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00000055a7ae9100
certificate:
  subject: CN=web.vrmd.de
  issuer:  CN=R3,O=Let's Encrypt,C=US
FEHLER: Keiner der alternativen Namen des Zertifikats stimmt mit dem angefragten Maschinennamen ‘foo.fastix.org’ überein.
Verwenden Sie »--no-check-certificate«, um zu dem Server foo.fastix.org eine nicht gesicherte Verbindung aufzubauen.
Closed 3/SSL 0x00000055a7ae9100

1. Der Server bekommt beim SSL-Connect keinen Hostnamen, für den ein spezielles Zertifikat vorgesehen ist, er nimmt das allgemeine. (wohl aus der default-ssl.conf)
2. Der Client protestiert beim Benutzer.