Verbindung zur Webseite via VPN ist nicht möglich - SSL / DNS Fehler?

Dafür müsste man wissen, was das für ein VPN ist und wie es arbeitet. Bei dem VPN scheint einiges krude zu sein, vor allem die DNS Funktionalität.

Die Fehlermeldungen lassen darauf schließen, dass bei der DNS Auflösung was schief geht und am Ende ein Standard-Plesk Zertifikat ausgeliefert wird. Wenn der Zugriff ohne VPN problemlos funktioniert, dann scheint da beim VPN einiges im Argen zu liegen.

Wie lange ist es her, dass du Domains und DNS Einträge vorgenommen hast? Vielleicht haben sie sich weltweit noch nicht herumgesprochen? Das dauert durchaus auch mal länger, als in der TTL angegeben.

Zitat von kombinat

Certificate #1: RSA 4096 bits (SHA256withRSA)

Revocation status Validation error

CRL ERROR: IOException occurred

DNS CAA No (more info)

Certificate #2: RSA 2048 bits (SHA256withRSA) No SNI

Common names Plesk

Alternative names - INVALID

Alles anzeigen

Ich denke, du hast beim ersten Zertifikat die Domain wegzensiert und nur das gequotet, was dir als Fehler erscheint. Das ist das Zertifikat, das du bekommst, wenn du beim Server korrekt mit dem Domainnamen im SNI anfragst. Es ist das richtige Zertifikat, und dass SSLlabs nicht nachschauen kann, ob das Zertifikat zurückgerufen wurde, ist normal. Du hast keinen CAA-Record im DNS deiner Domain hinterlegt. Das könnte man verbessern, also wird das markiert, aber es ist kein Fehler (orange, nicht rot). Das zweite Zertifikat ist das selbstsignierte Default-Zertifikat, das du bekommst, wenn du den Server ohne SNI befragst. Es ist normal, dass das nicht valide ist, weil der Server gar nicht weiß, mit welcher Domain du reden möchtest und deshalb auch kein dazu passendes Zertifikat präsentieren kann.

Warum die Website über VPNs nicht erreichbar ist, kann man nur mutmaßen. Die Webhosting-Systeme hier haben eine Firewall vorgeschaltet, die Angriffe abwehrt und Blacklisten führt. Es kann sein und ist wahrscheinlich, dass von den VPN-Exitnodes viel Schindluder getrieben wird, weil sich die Täter hinter dem VPN in Sicherheit fühlen. Dass man mit VPN-IP-Adressen nicht überall gerne gesehen ist (um es vorsichtig auszudrücken), kennt jeder, der sowas schon mal verwendet hat.

Zitat von kombinat

WIe kann ich das Problen angehen?

Anderen Hoster wählen oder Cloudflare* oder anderen Reverse Proxy Dienst vorschalten.

*) Die Besucher sehen dann öfter mal ein Captcha, bevor sie auf deine Seite kommen.

Zitat von kombinat

Ich denke nach wie vor, dass es ein serverseitiges Konfiguratiuonsproblem ist.

Ich nicht. Schöner fände ich, wenn die Firewall dokumentiert würde, also dass sie da ist und was sie sperrt. Aber daran, dass du mit einigen VPNs nicht auf den Webserver kommst, würde das nichts ändern.

Zitat von kombinat

Der Tool https://www.ssllabs.com/ssltest/analyze.html liefert :

Danke für den Link - kommt in die Werkzeugkiste

Screenshot 2025-12-06 at 18.56.01.png

Zitat von kombinat

@ A x.x.x.x

Den wirst du schon brauchen, wenn mit der Domain selbst der Webserver angesprochen werden soll. Alternativ ginge auch ein AAAA, aber das würde dich auf Clients mit IPv6-Unterstützung einschränken, und das könnte erklären, warum das über VPNs nicht geht. Das wäre dann kein Konfigurationsfehler des Servers sondern deiner Domain.

Na, wenn du von

@ A x.x.x.x

@ AAAA x.x.x.x

nicht wenigstens einen, normalerweise beide Einträge hast, dann mag das in "Unable to connect" resultieren , weil weder IPv4 noch IPv6 der Hauptdomain bekannt sind (per DNS). Irgendwo her sollte ja ssllabs schon wissen, wo sie nach der Domain suchen müssen. Bei der nx-Subdomain ist durch den Eintrag

nx A x.x.x.x

zumindest die IPv4 bekannt. Folglich kann die auch aufgerufen werden. Die Hauptdomain sollte weder mit noch ohne VPN funktionieren, außer du hast auf deinem PC

irgendwo die Adresse drin, z.B. in der /etc/hosts Datei (Windows: C:\Windows\System32\drivers\etc\hosts).

Zitat von tab

Irgendwo her sollte ja ssllabs schon wissen, wo sie nach der Domain suchen müssen.

SSLlabs hat den Server ja gefunden, denn sonst könnte das Zertifikat nicht analysiert werden. Ich halte es für wahrscheinlich, dass es einen AAAA-Record für die Domain selbst gibt, aber keinen A-Record. Das würde die beobachteten Probleme vollständig erklären. VPNs unterstützen IPv6 oft nicht, machen ihre Nutzer also zu IPv4-only Besuchern, die ohne A-Record den Server nicht finden. Sonst ist IPv6 verbreitet genug, dass der fehlende A-Record nicht schnell auffallen muss.

* A und * AAAA gilt für alle Subdomains, aber nicht für die nx-Subdomain, weil es für die einen Record mit Host nx gibt. Damit sind Wildcards wie * A oder * AAAA für die nx-Subdomain nicht relevant. Selbst wenn du nur einen nx A Eintrag hast und keinen nx AAAA, gilt auch der * AAAA trotzdem nicht mehr für die Subdomain nx. Wenn nx dann eine IPv6 Adresse haben soll, musst du den explizit setzen mit nx AAAA. Auch wenn es die selbe IPv6 ist wie bei * AAAA.