The most voted for answer is, unfortunately, wrong. It will have the desired effect, but for the wrong reasons. The commands in VonC's answer adds all certificates in the chain to the trust-anchor store. However, these certificates are not trust-anchors (or Root CA certificates in other words); they are the end-entity and intermediate CA certificates. The standard for TLS states: certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. Therefore VonC's (and others') command may well add all the wrong certificates and not the Root CA. A end-entity or intermediate CA certificate is not a trust-anchor. These certificate may and do change over time, in which case the same problem will rear it's ugly head again. Also, what happens if the end-entity certificate is revoked for some reason? Your computer may well continue to trust the revoked certificate - in practice, the exact response may depends on the crypto library being used as this isn't well defined in the standards and therefore subject to variation in implementation. The correct way to fix this would involve looking at the last certificate in the chain, confirming it is not a Root CA (as that may be sent by the server - see the RFC extract quoted above) and if that is the case, looking at the Issuer and potentially the AKI field to ascertain which Root CA issued this first intermediate CA certificate. Once the details have been worked out, you'll need to visit the repository of that Root CA and download (and verify the hash) of that certificate before downloading it. You should review the CP/CPS of this Root CA before deciding to install it in your trust-anchor store. If the last certificate is the Root CA, then use There can't be, and shouldn't be, an automatic process for you to carry out the above as you need to verify the provenance of the trust-anchor before you decide to add it to your trust-anchor store. Ask yourself why it wasn't part of the However, running something like the following will display the Subject and Issuer of the last certificate in the chain, which may help you trace down the missing Root CA certificate: Which (in my case in late May 2021) results in: From the above, we can see that the server sent the intermediate CA certificate, not the root (the subject and issuer are different). That intermediate CA certificate was signed by DigiCert's High Assurance EV Root CA. We can now go to DigiCert's repository and download that particular certificate. Before installing that certificate, make sure it is the one which signed your intermediate CA by running Once you're certain that the Root CA certificate you've downloaded is the correct one, and you've carried out due-diligence and decided that you trust this Root CA, add it to your trust-anchor store: Note that the file must be in PEM format and the filename must end in Hệ thống Email Server tại P.A được đầu tư & trang bị chứng chỉ SSL có trả phí nhằm bảo đảm an toàn cho khách hàng trong việc sử dụng dịch vụ, mã hóa các kết nối giữa client & server hoặc sử dụng Web Mail với giao thức https thay vì http để bảo mật hơn, giúp hạn chế việc mất hoặc dò password khi khách hàng sử dụng internet tại các nơi công cộng như quán cafe, nhà hàng, sân bay, … Chứng chỉ SSL này sẽ định kỳ gia hạn mỗi 2 năm 1 lần và khi tiến trình gia hạn thành công sẽ cập nhật lại chứng chỉ mới. Lỗi trên chỉ xảy ra khi bạn khai báo cấu hình mail client trên iPhone theo server mail.domain.com và sử dụng giao thức SSL (thay vì Non-SSL), đây chỉ là chứng chỉ SSL Self-Signed không đảm bảo an toàn và đã hết hạn, khi hết hạn sẽ không renew được như chứng chỉ SSL có phí. Để khắc phục cảnh báo trên bạn cần: + Khai báo lại server theo hostname mà P.A đã mua chứng chỉ SSL, hostname có dạng mailXX.maychuemail.com (trong đó XX sẽ thay đổi tùy thuộc vào server mà bạn sử dụng, có thể liên hệ kỷ thuật để được cung cấp chính xác hostname này) Server: mailXX.maychuemail.com SMTP SSL Port: 465 – SSL: Yes POP3 SSL Port: 995 – SSL: Yes IMAP SSL Port: 993 – SSL: Yes + Giữ nguyên server mail.domain.com tuy nhiên cần khai báo lại sử dụng Non-SSL (không bảo mật) Server: mail.domain.com (thay thế domain.com bằng tên miền của bạn) SMTP Port: 25 – SSL: No POP3 Port: 110 – SSL: No IMAP Port: 143 – SSL: No + Một số trường hợp khác cần xóa tài khoản email ra khỏi iPhone/iPad và Add lại mới cập nhật được. Bạn vào Settings > Passwords & Accounts > Chọn account mail.domain.com > Deleted Account Sau khi delete account bạn add lại tài khoản email vào iPhone/iPad theo hướng dẫn tại đây Trường hợp bạn muốn sử dụng SSL theo mail.domain.com cho chuyên nghiệp (không sử dụng SSL theo hostname của P.A cung cấp) và không phải cập nhật lại thiết bị khi gia hạn cần mua thêm chứng chỉ SSL mail.domain.com có phí tại địa chỉ: https://www.pavietnam.vn/vn/ssl-baomat.html Chú ý một số dịch vụ email shared (Email Pro) cần phải nâng cấp sử dụng gói Email Server Riêng mới cài đặt được SSL có phí theo mail.domain.com, bạn cần liên hệ kỷ thuật để được tư vấn chính xác nhất. |
