Sunt disperat:
Am mutat două domenii de la un server la altul care mergea fără probleme.
Am securizat ambele domenii (web și mail) cu certificate Letsencrypt.Acum, proprietarul acestor domenii s-a plâns de un server de e-mail care nu funcționează. Dar acest lucru nu putea fi, deoarece alte domenii ar putea trimite și primi e-mailuri.
În timpul depanării, am observat că nicio pagină web nu poate fi preluată de pe serverul meu pe macOS sau iOS. (Conexiune refuzată - Nu se poate stabili o conexiune sigură). Sub Windows/Linux/Android, toate acestea nu sunt o problemă și traficul de e-mail funcționează, de asemenea, impecabil. Deci, wtf se întâmplă? Se pare că Apple nu poate lucra cu certificatele Letsencrypt create. Ceea ce nu-mi pot imagina.
Are cineva idei despre asta?
Multumesc pentru ajutor.
Server: Ubuntu 20.04, gestionat de Plesk
Client: macOS Catalina, Apple Mail
---[EDITAȚI | ×]---
am fugit
openssl s_client -connect maildomain.com:465
pe o mașină Windows ȘI pe un Mac, pentru a verifica ce se întâmplă la conexiunea cu serverul meu de e-mail. Rezultatul pe un PC:
CONECTAT(00000003)
adâncime=2 C = SUA, O = Internet Security Research Group, CN = ISRG Root X1
verificați returnarea:1
adâncime=1 C = US, O = Let's Encrypt, CN = R3
verificați returnarea:1
adâncime=0 CN = maildomain.com
verificați returnarea:1
---
Lanț de certificate
0 s:CN = maildomain.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = SUA, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = SUA, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Certificat de server
-----ÎNCEPE CERTIFICAT-----
MIIFJzCCBA+gAwIBAgISBBHHETtaspqio7t1ZKYQ36xHMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTEwMDUwNzQyMjVaFw0yMjAx ... etc.
-----CERTIFICAT FINAL-----
subiect=CN = maildomain.com
emitent=C = SUA, O = Let's Encrypt, CN = R3
---
Nu s-au trimis nume de CA de certificat de client
Rezumat peer signing: SHA256
Tip semnătură peer: RSA-PSS
Cheie Temp Server: X25519, 253 de biți
---
SSL handshake a citit 4676 de octeți și a scris 395 de octeți
Verificare: OK
---
Nou, TLSv1.2, Cipher este ECDHE-RSA-AES256-GCM-SHA384
Cheia publică a serverului este de 2048 biți
Este acceptată renegocierea sigură
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Sesiune SSL:
Protocol: TLSv1.2
Cifr: ECDHE-RSA-AES256-GCM-SHA384
ID sesiune: DDE8ED4DBF7BD8E8F2D411EDE00C7522C0A15927E3D0C75F58F174B7464270D3
ID-ul sesiunii-ctx:
Cheie principală: 6D3167E0283ED9BA1F6427841212C8BAF37FF75998B369DE4184618EF9BFBE9F8860809CC9B7xxxxxxxxxxxxxxxxxxxx
Identitate PSK: Niciuna
Sugestie de identitate PSK: Niciuna
Nume de utilizator SRP: niciunul
Sugestie pentru durata de viață a biletului de sesiune TLS: 7200 (secunde)
Tichet sesiune TLS:
0000 - 21 be ab 05 b8 95 30 14-cf c1 ff 7d 98 aa 3c 82 !.....0....}..<. ... etc...
Ora de începere: 1633683311
Timeout: 7200 (sec)
Verificați codul de returnare: 0 (ok)
Secret principal extins: da
---
220 my.server.com ESMTP Postfix (Debian/GNU)
părăsi
221 2.0.0 Pa
închis
Și aici vine răspunsul pe un Mac:
CONECTAT(00000003)
341:error:1407742E:Rutine SSL:SSL23_GET_SERVER_HELLO:tlsv1 versiunea protocolului de alertă:S23_clnt.c:596:
Deci, se pare că Mac-ul nu poate face față TLS1.2/TLS1.3...
Orice sugestii ce să faci?
