On 28.12.2023 22:36, Carlos E. R. wrote:
On Thursday, 2023-12-28 at 18:36 +0300, Andrei Borzenkov wrote:
On 28.12.2023 16:57, Carlos E. R. wrote: ...
I had seen that thread back i July, but back then I did not read it complete, it worked before doing that.
Problem is, TB does not ask to create an exception.
Well, the intended way to use X.509 certificates is to sign them by known CA, not to rely on force accepting them by any particular program. Certificates not signed by a trusted authority are by definition not to be trusted.
Yeah, well... this is going to be used only by myself in my own machines, inside the LAN. Using true certificates would be a waste.
Which does not change a bit in the X.509 model. You must create CA and then sign certificate with this CA even if you do not realize it. openssl does it for you.
Currently, I have TB working by NOT using connection security.
Post <https://dovecot.org/list/dovecot/2022-September/125357.html> says to use extension "Subject Alt Names".
Next post (<https://dovecot.org/list/dovecot/2022-September/125383.html>) says to:
Practically this means you need to make sure that if you use self-signed or internal CA certificates you include subjectAlternativeName otherwise they won't work with some client software. If you use public CA-signed certs you typically don't need to do this yourself because the CA adds SAN if missing from the CSR (their only other option is to reject issuance).
I don't know what that means. Ie, I don't know what to add to dovecot-openssl.cnf, if that is what I have to do (and assuming if it is /etc/ssl/private/dovecot.* they are talking about.
"They" are talking about your certificate.
In a language I don't understand.
In the time of ubiquitous Internet that is a feeble excuse. But if you do not want to spend time learning how to manage certificates, you have your CA that will add this information to the signed certificate for you. But if you refuse to use CA, you need to learn how to do it properly yourself. ...
Ah, another post clarifies:
CN = example.com SAN.1 = example.com SAN.2 = www.example.com
Most likely the poster did not intend to spoon feed you and give you step by step recipe, but just overall requirement. *How* to add the Subject Alternative Name extension is documented in openssl manuals and in hundreds of the Internet search hits.
or
CN = www.example.com SAN.1 = www.example.com SAN.2 = example.com
...
Ok, trying to create new certificates:
Telcontar:/etc/dovecot # time bash ./mkcert.sh Generating a RSA private key ...............+++++ ........+++++ writing new private key to '/etc/ssl/private/dovecot.pem' ----- problems making Certificate Request 140165362526016:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:crypto/asn1/a_object.c:73: 140165362526016:error:0B083077:x509 certificate routines:X509_NAME_ENTRY_create_by_txt:invalid field name:crypto/x509/x509name.c:252:name=SAN
real 0m0.012s user 0m0.012s sys 0m0.000s Telcontar:/etc/dovecot #
It doesn't like that "SAN" thing. Blocked again.
Yes, because SAN should go into different section in the configuration file. And SAN may be of different type and you need to give the exact type (is it name, or IP or something else).
I have no idea what you did, where you added these lines or what this script does.
I am using the configuration and script files provided in the distribution.
/etc/dovecot/dovecot-openssl.cnf (copied from /usr/share/dovecot/dovecot-openssl.cnf and edited):
[ req ] default_bits = 1024 encrypt_key = yes distinguished_name = req_dn x509_extensions = cert_type
That is the section SAN should go into (there are also other possibilities).
prompt = no
[ req_dn ] # country (2 letter code) #C=FI C=ES
# State or Province Name (full name) #ST= ST=Murcia
# Locality Name (eg. city) #L=Helsinki L=Cartagena
# Organization (eg. company) #O=Dovecot O=Valinor
# Organizational Unit Name (eg. section) OU=IMAP server
# Common Name (*.example.com is also possible) #CN=imap.example.com CN = telcontar.valinor SAN = telcontar.valinor
Not here. ...
And SAN is just one /possible/ reason why certificate is not accepted. Yes, Thunderbird could be more helpful in explaining what it does not like.
(Thunderbird says nothing. It is dovecot which logs the complaint)
dovecot just informs you that a client did not like its certificate.
But what you do is not what they do in the dovecot thread I was reading.
I did add the Subject Alternative Name to the generated certificate. Exactly what they said.
They did:
CN = example.com SAN.1 = example.com SAN.2 = www.example.com
which I assumed goes into the dovecot certificate configuration file.
bor@bor-Latitude-E5450:/tmp/san$ diff -up carlos.conf ssl.conf --- carlos.conf 2023-12-29 11:05:22.348010259 +0300 +++ ssl.conf 2023-12-29 11:01:19.248547835 +0300 @@ -29,7 +29,7 @@ OU=IMAP server # Common Name (*.example.com is also possible) #CN=imap.example.com CN = telcontar.valinor -SAN = telcontar.valinor +#SAN = telcontar.valinor # E-mail contact @@ -39,3 +39,4 @@ emailAddress=postmaster@telcontar.valino [ cert_type ] nsCertType = server +subjectAltName = DNS:telcontar.valinor bor@bor-Latitude-E5450:/tmp/san$ openssl req -new -x509 -nodes -config ssl.conf -out dovecot.crt -keyout devecot.pem .......................................................................++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .............................................................++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ----- bor@bor-Latitude-E5450:/tmp/san$ openssl x509 -subject -fingerprint -noout -ext subjectAltName -in dovecot.crt subject=C = ES, ST = Murcia, L = Cartagena, O = Valinor, OU = IMAP server, CN = telcontar.valinor, emailAddress = postmaster@telcontar.valinor SHA1 Fingerprint=91:16:B5:2E:00:0E:8C:97:C9:65:0B:58:3F:C5:E7:8E:2E:01:A8:60 X509v3 Subject Alternative Name: DNS:telcontar.valinor bor@bor-Latitude-E5450:/tmp/san$