SSL für Admin-Interface [SOLVED]

[goldene-zeiten]

Hallo zusammen,

bei dem aktuellen Server wird beim Admin-Bereich immer das selbst signierte SSL-Zertifikat angezeigt, obwohl ich ausgewählt habe, dass für alle Dienste Lets Encrypt verwendet werden soll.

Was mache ich denn da falsch?

LG von

Hahni


[Mod-Edit]
Thread nach Fehler und Probleme verschoben.

[tab-kh]

Was wird denn im Panel unter Sicherheit ->SSL/TLS-Zertifikate -> Serverdienste absichern angezeigt? Wenn du da überall Let's Encrypt auswählst und speicherst, werden dann irgendwelche Fehler/Probleme angezeigt? Ich hatte z.B. mal das Problem, dass für den Server im DNS ein A und ein AAAA Record angegeben war, wobei der AAAA (IPv6) falsch eingetragen war. Dadurch wurde die Erstellung des Zertifikats verhindert, weil LE dann offenbar immer per IPv6 Verbindung aufnimmt, was dann eben fehlgeschlagen ist. Korrekte IPv6-Adresse im DNS eingetragen und schon hat es funktioniert.

[Alexander]

Hallo,

Etwaige Fehlermeldungen beim Beziehen von Let's Ecnrypt-Zertifikaten stehen unter "Systemstatus -> Protokolle (update.log, oder ssl-maintenance.log)" oder "Systemstatus -> Ereignis-Protokolle"

[goldene-zeiten]

Guten Morgen Alexander,

besten Dank für deine schnelle Antwort. Da findet sich folgendes:

Code: Select all

 
--
[15-May-2022 00:04:02] INFO  --> starting ssl certification maintenance
[15-May-2022 00:04:02] INFO  --> checking (normal) SSL/TLS certificates
[15-May-2022 00:04:02] INFO  --> check certificate "[ID 1]"
[15-May-2022 00:04:02] INFO  --> certificate name is "default"
[15-May-2022 00:04:02] INFO  --> certificate is valid until 2032-05-11 23:51:43 (3649 days left)
[15-May-2022 00:04:02] INFO  --> checking lets encrypt certificates
[15-May-2022 00:04:02] INFO  --> remove unused accounts / certificates
[15-May-2022 00:04:02] INFO  --> deleteDirectory(): perform rm -rf /etc/ssl/keyhelp/letsencrypt/keyhelp/
[15-May-2022 00:04:02] INFO  --> finished
====
[15-May-2022 00:46:48] INFO  --> starting ssl certification maintenance
[15-May-2022 00:46:48] INFO  --> checking (normal) SSL/TLS certificates
[15-May-2022 00:46:48] INFO  --> check certificate "[ID 1]"
[15-May-2022 00:46:48] INFO  --> certificate name is "default"
[15-May-2022 00:46:48] INFO  --> certificate is valid until 2032-05-11 23:51:43 (3649 days left)
[15-May-2022 00:46:48] INFO  --> checking lets encrypt certificates
[15-May-2022 00:46:48] INFO  --> remove unused accounts / certificates
[15-May-2022 00:46:48] INFO  --> deleteDirectory(): perform rm -rf /etc/ssl/keyhelp/letsencrypt/keyhelp/
[15-May-2022 00:46:48] INFO  --> finished
====
[16-May-2022 00:46:01] INFO  --> starting ssl certification maintenance
[16-May-2022 00:46:01] INFO  --> checking (normal) SSL/TLS certificates
[16-May-2022 00:46:01] INFO  --> check certificate "[ID 1]"
[16-May-2022 00:46:01] INFO  --> certificate name is "default"
[16-May-2022 00:46:01] INFO  --> certificate is valid until 2032-05-11 23:51:43 (3648 days left)
[16-May-2022 00:46:01] INFO  --> checking lets encrypt certificates
[16-May-2022 00:46:01] INFO  --> remove unused accounts / certificates
[16-May-2022 00:46:01] INFO  --> check domain "hyperbrain.hahnefeld.it'
[16-May-2022 00:46:01] INFO  --> certificate file does not exist
[16-May-2022 00:46:01] INFO  --> renew cert
[16-May-2022 00:46:01] INFO  --> Using certificate authority: "https://acme-v02.api.letsencrypt.org/" (LIVE).
[16-May-2022 00:46:01] INFO  --> Getting endpoint URLs.
[16-May-2022 00:46:02] INFO  --> Account "keyhelp" already registered. Continue.
[16-May-2022 00:46:02] INFO  --> Requesting Key ID.
[16-May-2022 00:46:02] INFO  --> Sending signed request to "https://acme-v02.api.letsencrypt.org/acme/new-acct".
[16-May-2022 00:46:03] INFO  --> Start certificate generation.
[16-May-2022 00:46:03] INFO  --> Token stored at: /home/keyhelp/www/.well-known/acme-challenge/local-check-628182ab34d213.38896137
[16-May-2022 00:46:18] INFO  --> Curl: Connection timed out after 15002 milliseconds (http://server.tld/.well-known/acme-challenge/local-check-628182ab34d213.38896137)
[16-May-2022 00:46:18] ERROR --> a Let's Encrypt error occurred: Local resolving checks failed for domain "server.tld". Please ensure that your domain is locally resolvable!
[16-May-2022 00:46:18] INFO  --> finished
====
--

LG von

Hahni

[Alexander]

Code: Select all

[16-May-2022 00:46:18] ERROR --> a Let's Encrypt error occurred: Local resolving checks failed for domain "server.tld". Please ensure that your domain is locally resolvable!

Dann einmal die Erreichbarkeit der betroffenen Domain über die Konsole auf deinem Server überprüfen. Deine Domain kann lokal nicht aufgelöst werden.

[goldene-zeiten]

Ich kann bedauerlicherweise keinen Unterschied zu meinem anderen weiteren Server finden. Beim alten ersten Server geht es, beim neuen nicht. Beide Subdomians/Hostnamen sind hinterlegt und unter IPv4 und IPv6 erreichbar.

[Alexander]

Versuche z.B. mit wget auf der Konsole auf dem betroffenen Server die Domain zu erreichen - dann sollte eine Fehlermeldung erscheinen.

[goldene-zeiten]

Das stimmt eindeutig - da hast du Recht:

--
ERROR: cannot verify domain.it's certificate, issued by ‘emailAddress=info@keyhelp.de,CN=domain.it,OU=KeyHelp Panel,O=KeyHelp,L=Erfurt,ST=Thuringia,C=DE’:
Self-signed certificate encountered.
To connect to domain.it insecurely, use `--no-check-certificate'.
--

Doch wie kann ich das beheben? Die Einträge in der /etc/hosts müssten meiner Meinung nach stimmen.

Es gibt einmal einen Eintrag für 127.0.0.1 und localhost und einen für die echte IP und den Hostnamen. Das ist doch soweit richtig?

[Alexander]

Kannst mir auch mal die SSH Zugangsdaten zukommen lassen, dann schau ich einmal (per PM).

[goldene-zeiten]

Ich hätte es natürlich auch sehr gerne selbst lösen wollen. Vor allem auch, weil ich es beim anderen Server auch hin bekommen habe. Im Forum hatte ich gesehen, dass die /etchosts/ eine potentielle Fehlerquelle sein könnte... Aber ich meine, die ausschließen zu können.

[goldene-zeiten]

Ich habe kurzerhand den Server neu aufgesetzt. Der war ja noch jungfräulich. Und dann habe ich - vor der Installation von Keyhelp - die "/etc/hostname" auf den tatsächlichen Namen umgestellt. Ionos hat da temporäre Hostnamen. Ich meine, dass dies der Grund war. Die erste Webseite läuft sauber. Aber dafür gibt es mit den Mails noch Probleme:

--
host mx00.ionos.de[212.227.15.41] refused to talk to me: 554-kundenserver.de (mxeue010) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://www.ionos.com/help/index.php?id ... 117&c=rdns
--

[Jolinar]

Die Fehlermeldung ist doch eindeutig:

Code: Select all

554-Bad DNS PTR resource record

[goldene-zeiten]

Wie könnte ich das beheben? Der Hostname müsste sich doch sauber auflösen lassen. Das ist doch genau genommen der PTR?

[Jolinar]

Wie könnte ich das beheben?

Sorry, aber das ist absolutes Grundlagenwissen, welches jeder Serveradmin im Schlaf beherrschen muß!
Ich rate dir dringendst, deine Kenntnisse über das Domain Name Sytem zu verbessern...

Hier etwas Lesestoff;
https://de.wikipedia.org/wiki/Domain_Name_System
https://de.wikipedia.org/wiki/PTR_Resource_Record
https://de.wikipedia.org/wiki/Reverse_DNS

Und zu deinem Problem:
https://www.google.com/search?q=554-Bad ... rce+record

[goldene-zeiten]

Wenn man einen Server bei Ionos hat (Dedicated Server), kann und muss man das im Cloud Panel unter Netzwerk -> Öffentliche IP eintragen. Somit scheinen die Mails nun auf dem KeyHelp-Server durchzugehen - jedenfalls landet keine mehr in der Warteschleife. Die Mails kommen nun auf den nächsten Mail-Server bei Ionos an. Allerdings werden sie von dort nicht mehr an Gmail weitergeleitet. Also Versand an KeyHelp-Server klappt. Die Weiterleitung zu Ionos auch - daher PTR-Problem gelöst. Aber den Weg zu Gmail finden sie nicht (2. Weiterleitung).