Verlängerung AlphaSSL Wildcard-Zertifikat für PD-Admin Host | SMTP aus Webanwendung nicht mehr erreichbar

    Hallo, wir haben turnusgemäß unsere SSL-Zertifikate auf den PD-Admin Servern erneuert. Dabei neue AlphaSSL (nachfolge von GlobalSign) verwendet.
    Jetzt ist nach der Installation mit dc-ssl-install.sh es nicht mehr möglich per SMTP aus Webanwendungen wie wordpress oder Gambio Mails zu versenden.

    Da kommt dann das die Verbindung zum Host nicht aufgebaut werden kann.


    Nehme ich die alten, noch 2 wochen gültigen, Zertifikate funktioniert es wieder.


    Wo liegt dann da der Fehler? Gibt es Zertifikate die nicht gehen? Was hat das mit der SMTP-Verbindung zu tun?


    Hat jemand einen Rat?


    Nachtrag1:

    anscheinend ist das nicht auf allen Servern der fall. Wir haben einige noch mit Debian9 und nicht ganz aktuellen SE/PD-Admin... Kann es evtl. an der Speicherzuteilung liegen?
    Ist auf jedenfall total komisch, denn mit dem alten Zertifikats-Set (key-cert-cacert) geht alles problemlos und mit dem neuen tritt der Fehler auf.


    Nachtrag2:
    Der Fehler der im Wordpress gravity forms erzeugt wird lautet

    SMTP Error: Could not connect to SMTP host. Failed to connect to serverSMTP server error: Failed to connect to server


    Das verhalten ist echt komisch und kann ich mir nicht erklären. finde dazu auch nix. Ob es wirklich auf manchen Maschinen geht kann ich gar nicht zweifelsfrei sagen, da dort andere Konfigurationen verwendet werden.




    vielen lieben Dank
    Manfred

    Kommen nach der Zerti Änderung die SMTP Dienste überhaupt hoch? Also hast Du danach was Listening auf die Ports 25, 587 und 465 wenn Du netstat -lpn machst?


    Welche SMTP Parameter sind in diesem Gravityforms eingestellt? Hostname, Port, SSL Ja/nein etc.

    Ich bin mir übrigens nicht sicher, ob man auf aktuellen Umgebungen das dc-install für den Zertifikatswechsel noch einsetzen sollte. Das /opt/pdadmin/bin/update_host_certificate.sh sollte den Job eigentlich machen.

    Alle SMTP-Dienste sonst laufen problemlos, lediglich aus dem Apache bzw. der Website kann keine Hostverbindung aufgebaut werden.
    Das ist total seltsam weil es auch nix in den logfiles dazu gibt.


    Habe es mit und ohne SSL/TLS auf allen Ports 25, 465, 587 probiert... mit einer einlieferung über outlook alles kein problem.


    Nehme ich das alte Zertifikatssetup gehts auch gleich wieder (ich spiele die Zertifikate so ein: -key/-cert/-cacert (intermed+root) in /opt/pdadmin/sslcerts kopieren und dann dc-ssl-install.sh ausführen.


    Aktive Internetverbindungen (Nur Server)

    Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

    tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 31354/dovecot

    tcp 0 0 213.239.204.197:9292 0.0.0.0:* LISTEN 2104/sshd

    tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 31354/dovecot

    tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 31354/dovecot

    tcp 0 0 0.0.0.0:4190 0.0.0.0:* LISTEN 31354/dovecot

    tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 31354/dovecot

    tcp6 0 0 :::587 :::* LISTEN 7965/tcpserver

    tcp6 0 0 :::80 :::* LISTEN 744/httpd

    tcp6 0 0 :::465 :::* LISTEN 7964/tcpserver

    tcp6 0 0 :::21 :::* LISTEN 754/proftpd: (accep

    tcp6 0 0 :::25 :::* LISTEN 8063/tcpserver

    tcp6 0 0 :::443 :::* LISTEN 744/httpd


    Server mit neuer Zertifikatskette: https://server17.onit4u.de/customer
    Server mit alter Zertifikatskette: https://server16.onit4u.de/customer


    Ich habe das ganze ja jetzt schon zig mal gemacht und nie hat es probleme beim Tauschen und erneuern der Zertifikate gegeben.

    Ich habe mir das /opt/pdadmin/bin/update_host_certificate.sh angeschaut, und es macht prinzipiell das gleiche, zumindest werden die zertifikate an die gleichen Stellen gepackt. Das ist ja das absolut komische und nicht nachvollziehbare....


    Ich finde auch keine Zusammenhang dazwischen das der Server (dovecot oder qmail) plötzlich keine SMTP-Verbindung mehr von der eigenen IP entgegen nimmt bzw. nicht verfügbar ist, obwohl der Dienst normal läuft.

    Ich habe nun ein Certum Commercial SSL Wildcard Zertifikat gekauft um es mal mit einem anderen Zertifikat zu probiere.
    Sehr kurios, mit dem Certum-Zertifikat funktioniert alles tadellos.     Damit gebe ich das AlphaSSL-Zertifikat zurück. Keine Ahnung was da in der Zertifikatskette für ein Problem war. Damit ist es zwar behoben, aber eine Erklärung habe ich nicht.

    Die Informationen im Ticket sind leider auch sehr waage... Es bräuchte einmal die genaue Angabe, wie eine Mail versandt wird. Denn Port 25, 465 und 587 sind jeweils eigene Dienste.


    Dann sollte auf der Konsole einmal das Zertifikat geprüft werden:

    Code
    echo "" | openssl s_client -servername server17.onit4u.de -connect server17.onit4u.de:465 | openssl x509 -noout -dates
depth=2 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA
verify return:1
depth=1 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Domain Validation CA SHA2
verify return:1
depth=0 CN = *.onit4u.de
verify return:1
DONE
notBefore=Oct 16 11:13:02 2024 GMT
notAfter=Oct 16 11:13:01 2025 GMT

    Dies ist aber vermutlich schon das neue Zertifikat...


    Dann hätte man im nächsten Schritt den Versand mit einem kleinen PHP Skript prüfen müssen. Also nicht aus Wordpress heraus.

    danke für die Infos, ich habe das alte Zertifikat noch nicht zurück gezogen, da mache ich nochmal ein paar tests damit, vielleicht werde ich ja schlauer.
    dann lasse ich es euch natürlich wissen.


    Habe alle drei Ports probiert ohne jegliche Änderung

    habe nochmal das nicht funktionierende Zertifikat installiert

    Ja, ohne SSL auf Port 25 hätte es meines erachtens auch gehen müssen.


    Das AlphaSSL-Zertifikat läuft auch normal, bis auf die SMTP-Verbindungen aus einer Webanwendung (PHP) heraus auf die eigene Maschine.


    echo "" | openssl s_client -servername server17.onit4u.de -connect server17.onit4u.de:465 | openssl x509 -noout -dates

    depth=2 OU = GlobalSign Root CA - R6, O = GlobalSign, CN = GlobalSign

    verify return:1

    depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign GCC R6 AlphaSSL CA 2023

    verify return:1

    depth=0 CN = *.onit4u.de

    verify return:1

    DONE

    notBefore=Oct 13 06:26:20 2024 GMT

    notAfter=Nov 14 06:26:19 2025 GMT




    echo "" | openssl s_client -servername server17.onit4u.de -connect server17.onit4u.de:25 | openssl x509 -noout -dates

    140691117219904:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252:

    unable to load certificate

    139902321950784:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:686:Expecting: TRUSTED CERTIFICATE




    echo "" | openssl s_client -servername server17.onit4u.de -connect server17.onit4u.de:587 | openssl x509 -noout -dates

    139932140716096:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252:

    unable to load certificate

    140466228752448:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:686:Expecting: TRUSTED CERTIFICATE




    Egal, ich kann es ja noch stornieren und zurückgeben ohne das ich dafür Kosten habe, außer den Ärger und die Arbeit damit.

    Zitat von monderka

    echo "" | openssl s_client -servername server17.onit4u.de -connect server17.onit4u.de:25 | openssl x509 -noout -dates


    Zitat von monderka

    echo "" | openssl s_client -servername server17.onit4u.de -connect server17.onit4u.de:587 | openssl x509 -noout -dates

    Die Befehle sind falsch. Auf Port 25 und 587 kommt nicht TLS, sondern STARTTLS zum Einsatz. Es muss dabei noch "-starttls smtp" ergänzt werden:

    Code
    echo "" | openssl s_client -servername server17.onit4u.de -starttls smtp -connect server17.onit4u.de:587 | openssl x509 -noout -dates

    Aber da das Zertifikat ja über outlook und normale SMTP-Verbindungen von einem drittserver, PC mit allen Ports korrekt funktioniert hat, nur nicht bei Zugriffen aus PHP auf dem eigenen Server liegt des wohl eher wirklich an openssl oder dem PHP-SSL-Parser. Auf beiden Maschinen auf denen das aufgefallen war war nicht die neueste PDA Version und SE drauf und Debian9. Kann sein das es mit aktuellem PDA/SE funktioniert hätte.

    Da ich aber auf die schnelle keine Updates drüber bügeln wollte ist das mit einem anderen Zertifikat nun erstmal für mich OK.

    Okay, ich hab Dich missverstanden glaub ich. Ich hatte Dich so verstanden dass es auf den aktuellen Server nicht geht, auf den noch nicht upgedateten aber schon. Anscheinend ist es umgekehrt.


    In dem Fall kann es auch sein, dass auf den älteren Servern zum Beispiel das ca-certificates Bundle nicht mehr aktuell ist.

    hatte auch mit update-ca-certificates zwar alles aktualisiert und das für AlphaSSL nötige Rootzertifikat war auch überall mit drauf.

    Ob es bei neueren Servern funktioniert hat oder nicht kann ich nicht sagen, da hat sich nur kein Kunde gemeldet und ich habe dort nirgends eine testbare Installation von Gambio oder Wordpress mit GravityForms drauf gehabt.


    Dadurch das ich die Zertifikate 30 Tage lang bei PSW stornieren kann passiert ja nix, habe jetzt einfach ein anderes gekauft das geht.
    Hat mich nur gewundert weil die letzten 4 Jahre auch AlphaSSL-Zertifikate drauf gelaufen sind.


    Danke euch für den Input. ich bleibe da auch dran und wenn sich irgendwas zur Klärung findet lass ich es hier für alle zurück.
    Das Forum ist ja unser wichtigstes Nachschlagewerk