You probably just forgot to copy/link one of the files.
Or maybe that chmod command that messes with certbot.
3 Likes
In /etc/ssl/private/*** initially were files: cert.pem, chain.pem, fullchain.pem, fullchain.srt, privkey.pem, privkey.key after certbot installation they are static links to
\etc\letsencrypt\live\ (cert.pem, chain.pem, fullchain.pem and privkey.pem) renewed by certbot, so they are point to \etc\letsencrypt\archive*** (certNN.pem, chainNN.pem, fullchainNN.pem and privkeyNN.pem) - real key files formed by certbot
Some links go in /etc/ssl/certs, according to that document.
3 Likes
Actually it is confusing. Installation was not done by me, but I installed certificates initially by hands instead of old ones. The working certificates was definitely in /etc/ssl/private/***, not "
ssl_certificate /etc/ssl/certs/iRedMail.crt;
ssl_certificate_key /etc/ssl/private/iRedMail.key "
I don't know what to tell you. Moreover, your dovecot is presenting the correct certificate with the proper chain.
Something happened that made postfix behave differently.
3 Likes
Now it is with cert.pem with manually copied second certificate.
It looks like it works
❯ echo "" | openssl s_client -connect mail.protorg.msk.ru:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mail.protorg.msk.ru
verify return:1
---
Certificate chain
0 s:CN = mail.protorg.msk.ru
i:C = US, O = Let's Encrypt, CN = R3
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
v:NotBefore: Jul 10 19:07:13 2023 GMT; NotAfter: Oct 8 19:07:12 2023 GMT
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEJjCCAw6gAwIBAgISBHc7+7f/nxN+j40AmCgMuzHhMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzA3MTAxOTA3MTNaFw0yMzEwMDgxOTA3MTJaMB4xHDAaBgNVBAMT
E21haWwucHJvdG9yZy5tc2sucnUwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATv
GwaEwdBjR6IV4XWRIvP5Pzgv42cO656fcd9qBWcTiOk6NBJw9qG4doAZGlrSo33D
A8YiE7HlwEqmjV8vQXBUo4ICEzCCAg8wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQS
BFNsMkDwSJYw+RqLSDEHWVVznTAfBgNVHSMEGDAWgBQULrMXt1hWy65QCUDmH6+d
ixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9yMy5vLmxl
bmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3JnLzAeBgNV
HREEFzAVghNtYWlsLnByb3RvcmcubXNrLnJ1MBMGA1UdIAQMMAowCAYGZ4EMAQIB
MIIBAgYKKwYBBAHWeQIEAgSB8wSB8ADuAHUAtz77JN+cTbp18jnFulj0bF38Qs96
nzXEnh0JgSXttJkAAAGJQWpPfwAABAMARjBEAiA71RkrisxHIe6nxUs+AJam6FHW
igWpitPDRsR/tTtMlwIgXP9PdLYCu4Ylrjq6gTS348L8S2/+/bvFJS3CIbSfoW8A
dQB6MoxU2LcttiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYlBak+lAAAEAwBG
MEQCICbuj/qbNNzHHHj4r3eE55lg1TBGfw3cAmY6Qgj3qfPAAiB71jDc2L5PdnFp
z/OBYb1JZEazuP+jTC0KzyXgaptSijANBgkqhkiG9w0BAQsFAAOCAQEAJYNDBgpd
ITU7j2Z5U1zchRTWhoKHtVSxofxyJNYsV3d0Dwy/iVbh7atcHNRAmIxnwSIuDI07
yrAZ+7s9lbSoG6BdDp35ZD6nRW0/gxnq3VjLLCV0SsxO8A+cALs3BK9ZfWpZ0ru8
35kwgVtkK1WPBF0W412c4+nHdhxlzqvG0cAOR5Zg1AN5emzkCTPTtWP/GGqezN/+
Rofmi85cJc9Azdi7aVVwZZkHUKab5x+/76lRvXsZxRxtJfUtkwbPBxh6RUnusq+X
f4SXITMcirp0QYHGnU1eIK8FS5moR4zay079+7AGrYGkD8wfZiJTheU/R4BITGpL
3+ZkiDKWCPAnEA==
-----END CERTIFICATE-----
subject=CN = mail.protorg.msk.ru
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3018 bytes and written 434 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 CHUNKING
DONE
~ took 6s
4 Likes
That sounds unnecessary OR hard to automate.
What is the automated solution?
3 Likes
This is exactly my question! How to automate it and why it behaves like this.
Well, the topic title is a given.
If the fullchain.pem fails and the cert.pem+"second certificate" works...
Then you may need to request a cert with the short chain and use that fullchain.pem file.
OR
Request a cert from some other free CA.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.