Hi Maintainer mail/courier-imap work fine before FreeBSD 14-RELEASE I updated system to FreeBSD 14-RELEASE with ports version OpenSSL 3.0(Not FreeBSD bundle OpenSSL 3.0) After update, most of IMAP client can not receive mail like Thunderbird @ Ubuntu and Apple Mail @ MAC OS, (except iPhone iOS mail app, it work), and got error message when all of IMAP client access as follows.. Dec 12 13:47:47 mail imapd-ssl[34757]: ip=[2001:b400:e52f:25bf:8dbc:2103:b6ed:9da2], couriertls: /usr/local/etc/courier-imap/certificate/fullchain.pem: error:1E08010C:DECODER routines::unsupported I had turn on build option "LEGACY" (Older algorithms) support @ OpenSSL 3.0, but won't work still. Thanks a lot.
Hi, I am using courier-imap on 14.0, but linking to the OS included OpenSSL (OpenSSL 3.0.12 24 Oct 2023 (Library: OpenSSL 3.0.12 24 Oct 2023)), and it is working fine. I don't know what could be going wrong in your case right away. First question that comes to mind, since the error message cites your certificate file is, what kind of certificate is it? What algorithm is it using? By the format of the error I can telle it looks generated by OpenSSL itself, and not by courier-imap (this does not mean it is excluded that courier-imap is at fault, just an indication where the error message is spilling from, the cause could be elsewhere), so I will need to research it. I don't think the legacy option has anything to do with it, unless you know for sure you have configured courier-imap to use legacy algorithms.
A quick search on google yielded two promising results: https://stackoverflow.com/questions/74131595/error-error1e08010cdecoder-routinesunsupported-with-google-auth-library https://github.com/nodejs/help/issues/4115 I understand you cannot share the key file, but maybe you can share the public certificate (no reserved information in there) Looks like it is a file format problem, maybe newer OpenSSL is unable to read the raw format and needs it base64 encoded, and maybe it can't correctly interpret your newlines. Could you try modifying your cert file format following the suggestions in the links above? (keep a backup of the original file, obviously!)
Created attachment 247017 [details] Problem fullchain.pem
Hi Guido Falsi The fullchain.pem file is Let's Encrypt and generated by security/py-certbot ports. Generate argument: rsa_key_size = 4096 key_type = ecdsa elliptic_curve = secp384r1 Please reference problem fullchain.pem @ attachment file. The fullchain.pem/privkey.pem pairs work fine with Apache 2.4, vsFTPD, and Postfix @ current ports version OpenSSL-3.0.12 with 14-RELEASE. About legacy option @ mail/courier-imap Please tell me this information because does not find @ ports make options as follows. # This file is auto-generated by 'make config'. # Options for courier-imap-5.2.6,2 _OPTIONS_READ=courier-imap-5.2.6,2 _FILE_COMPLETE_OPTIONS_LIST=AUTH_LDAP AUTH_MYSQL AUTH_PGSQL AUTH_SQLITE AUTH_USERDB AUTH_VCHKPW DOCS GDBM GNUTLS INOTIFY IPV6 TR ASHQUOTA OPTIONS_FILE_UNSET+=AUTH_LDAP OPTIONS_FILE_SET+=AUTH_MYSQL OPTIONS_FILE_UNSET+=AUTH_PGSQL OPTIONS_FILE_UNSET+=AUTH_SQLITE OPTIONS_FILE_UNSET+=AUTH_USERDB OPTIONS_FILE_UNSET+=AUTH_VCHKPW OPTIONS_FILE_UNSET+=DOCS OPTIONS_FILE_UNSET+=GDBM OPTIONS_FILE_UNSET+=GNUTLS OPTIONS_FILE_SET+=INOTIFY OPTIONS_FILE_SET+=IPV6 OPTIONS_FILE_SET+=TRASHQUOTA Note: I have never touch these options when update to 14-RELEASE Thank a lot.
(In reply to epopen from comment #4) I'll state again that I have never seen this error myself and I have no idea where it could come from, so I'm trying to understand it and asking information that I think could be helpful, but I'm not sure what is going on. It could take some time t understand what is going wrong in your system. While I am confident at this point your certificates are correct, what you uploaded has been redacted and is not useful for any kind of analysis. I don't understand why you feel the need to redact public certificates, which, if you server was working, would be anyway accessible in full detail to anyone connecting to your server. I thought the certificates needed checking because I found information about that causing the same error you get and so was worth a try. One thing I'd like to view is the output of "ldd /usr/local/bin/couriertls" to check exactly to which libraries it is linking. Maybe the port is linking it to the wrong ssl library causing conflicts. Also, you could try doing "openssl x509 -in fullchain.pem -text -noout" and see if it works fine (it should, but just in case), giving you the decoded details of the first cert in the chain. I don't use py-certbot but is it also providing the private key and installing it unmodified? You should really verify the format and especially the newlines in your private key file. I'd suggest checking it with an hex editor or a text editor that displays non printable characters. Finally a thing worth trying is doing a "pkg install -f" for openssl end the courier-imap ports, just in case. It is not elegant but it sometimes is the real solution. At worst nothing changes.
(In reply to Guido Falsi from comment #5) Regarding the pkg install -f, I forgot you are not using binary packages (I guess), so, you should rebuild the ports. If you do rebuild the courier-imap port could you grab the output of the full build and attach it? Maybe there could be useful information there too. Another thing that comes to mind, after upgrading from 13.x to 14.0, you did rebuild all the ports you're using? That's mostly mandatory for major upgrades. If not done it is quite probable things will get broken.
Created attachment 247020 [details] Problem fullchain.pem (Original not edit)
Created attachment 247021 [details] Build mail/courier-imap log
Hi Guido Falsi Sorry, I edit file before upload always, but fullchain.pem is public key I forgot. Therefore I upload original version for you reference again. Can you visit https://www.epopen.com ? It using same cretificate (Alomst because added Online Certificate Status Protocol (OCSP)) About "ldd /usr/local/bin/couriertls", result as follows libssl.so.12 => /usr/local/lib/libssl.so.12 (0x3e555b427000) libcrypto.so.12 => /usr/local/lib/libcrypto.so.12 (0x3e555a6a6000) libidn2.so.0 => /usr/local/lib/libidn2.so.0 (0x3e555c409000) libc.so.7 => /lib/libc.so.7 (0x3e555da7d000) libthr.so.3 => /lib/libthr.so.3 (0x3e555cf11000) libunistring.so.5 => /usr/local/lib/libunistring.so.5 (0x3e555e67a000) [vdso] (0x3e5559f5f000) libssl.so.12 and libcrypto.so.12 provide from ports version of OpenSSL. (/usr/local/lib/libcrypto.so.12 was installed by package openssl-3.0.12_1,1) About "openssl x509 -in fullchain.pem -text -noout", my result: Certificate: Data: Version: 3 (0x2) Serial Number: 04:a6:f1:42:f2:2d:2f:b3:0a:9c:63:48:53:10:61:bc:f3:da Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = R3 Validity Not Before: Dec 12 02:54:25 2023 GMT Not After : Mar 11 02:54:24 2024 GMT Subject: CN = epopen.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:e1:c5:02:34:75:e6:d4:9f:47:df:6b:b0:1d:5d: 5b:0d:91:64:61:fa:73:89:de:8f:26:15:f8:72:2e: f0:10:bc:4b:53:0c:f1:42:56:e6:5b:fc:8f:37:6a: 1b:b3:ce:dc:8b:d1:c4:5e:ce:08:5d:21:2d:f2:38: 97:f4:63:9a:dc:33:18:50:19:7a:3f:d1:a1:1d:d1: 04:39:05:53:a1:d6:a6:57:85:c1:dc:b7:f9:43:9d: 6e:01:2d:9e:e5:e7:5d ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Authority Key Identifier: 14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6 Authority Information Access: OCSP - URI:http://r3.o.lencr.org CA Issuers - URI:http://r3.i.lencr.org/ X509v3 Subject Alternative Name: DNS:*.epopen.com, DNS:epopen.com X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 48:B0:E3:6B:DA:A6:47:34:0F:E5:6A:02:FA:9D:30:EB: 1C:52:01:CB:56:DD:2C:81:D9:BB:BF:AB:39:D8:84:73 Timestamp : Dec 12 03:54:25.534 2023 GMT Extensions: none Signature : ecdsa-with-SHA256 30:44:02:20:73:BB:90:47:49:EA:09:F0:BD:D1:83:C0: F2:44:B0:A9:77:51:98:64:24:29:D3:0D:6F:1A:80:E1: 26:8E:28:6B:02:20:0D:AC:6B:DC:7E:F4:FF:AD:7E:5D: 1E:42:EF:FE:C0:81:25:68:82:21:6D:72:A4:34:76:DF: BC:1A:72:B1:48:EA Signed Certificate Timestamp: Version : v1 (0x0) Log ID : EE:CD:D0:64:D5:DB:1A:CE:C5:5C:B7:9D:B4:CD:13:A2: 32:87:46:7C:BC:EC:DE:C3:51:48:59:46:71:1F:B5:9B Timestamp : Dec 12 03:54:25.526 2023 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:21:00:8D:3F:C3:0C:1A:2F:E6:75:2C:DF:85: B8:96:80:0F:2B:F2:5E:A9:27:44:88:49:F6:18:93:D9: C6:74:41:9D:5E:02:20:7A:31:28:C3:DB:7D:90:43:67: 9C:3A:6F:9B:20:48:F7:68:D6:E3:75:DA:4A:3D:0C:45: 9D:07:E1:8D:22:6F:48 Signature Algorithm: sha256WithRSAEncryption Signature Value: 3f:cb:2c:b1:8b:2c:46:4a:98:8a:84:b3:1e:94:87:1b:a0:4d: de:e0:06:fd:5e:0a:ef:4a:9d:e1:f6:87:80:e7:d6:5d:f4:ec: e1:48:51:a4:01:ce:b1:3e:5f:57:3b:7a:05:1d:1a:40:0f:04: 3d:b1:d0:f6:68:70:ae:cb:8d:61:b8:e4:89:b0:19:18:fa:2a: 73:67:9b:46:46:d8:4a:1f:b4:58:b3:d6:17:f0:d9:d4:5b:2d: d2:76:cf:53:85:fc:9e:0d:b7:09:85:41:fc:84:73:47:d6:c5: 46:79:37:17:7f:c6:68:f9:b3:64:7d:a3:0a:6b:1b:e6:9d:e3: 80:13:eb:12:f0:d9:e2:2b:68:f0:d1:2a:05:8b:02:71:86:0c: 17:f7:fd:21:6a:78:04:83:0e:b1:7f:b8:9e:e6:78:1e:fc:66: 1d:1e:3b:7a:a5:a0:34:91:fe:cc:bf:77:8c:33:72:bf:3e:ab: 55:a8:10:4c:45:b0:68:2b:39:26:8d:f7:94:7d:1c:27:a1:cc: 85:f1:d8:81:97:e4:15:ec:90:a3:44:6b:f8:7d:82:e2:09:e6: 05:de:e0:ac:46:19:fa:11:7f:cc:42:e5:31:e1:02:ae:05:76: cb:33:85:50:8f:aa:d1:1a:81:8c:e9:a3:09:3e:8e:76:d8:3b: 4a:3a:3e:b1 Look like good. Yes, I had been rebuild all of ports by "portmaste -af" About mail/courier-imap build result Please reference attachment file "courier-imap_BuildLog". Thanks a lot.
I have tried to reproduce your issue in a virtual machine, by manually compiling all ports to use ports provided openssl (openssl-3.0.12_1,1), I generated a certificate as similar to yours as I could, using a local CA. courier-imapd-ssl start successfully and listens for connections. So I am unable to reproduce your problem. I admit I have no idea at this point what could be causing your problem. My best guess is that openssl fails to parse your certificate private key. You should try forcing to regenerate that via py-certbot or verify the private key is actually correct. What happens if you try to run "openssl ec -noout -in <your private key file> -text"? Is openssl able to read and output the information? If you get the key information you could paste the NIST CURVE field? That is no secret information, I expect "P-384" The fact that I can connect to your website does not prove anything. The certificate being similar is not important, it is not the same, and anyway, it looks like your problem is being caused by the key file, and I guess you are not using the same key for the webserver and the imap server.
Hi Guido Falsi First, thanks your hard work very much. About "openssl ec -noout -in ./privkey.pem -text" result as follows. read EC key Private-Key: (384 bit) priv: 12:3a:49:54:63:2c:be:37:ea:ad:43:17:9a:b7:5d: ... ... 62:d3:20 pub: 04:e1:c5:02:38:67:da:b1:db:47:df:6b:b0:1d:5d: ... ... ... ... ... 6e:01:3d:1e:35:e4:5d ASN1 OID: secp384r1 NIST CURVE: P-384 P-384 and other look good like. About key of webserver and the imap server. Almost same expect webserver because using OCSP feature added key. Other server (vsftp and postfix) using key same with courier-imap server.
I'm sorry at this point I'm out of ideas on what could be wrong with your system. One thing worth trying is you replicating the same setup in a clean jail or vm installing ONLY courier-imap and using the same certificate and key. As I said before the fact that other services are working fine with similar key/certs is of no help in shedding life why courier-imap is failing. I'm CCing brnrd@FreeBSD.org who maintains the openssl port, maybe he could give us some insight and have some suggestion on how to proceed. @brnrd I'mm adding you here because I'm of ideas, so if you could provide any kind of feedback or suggestion that would be greatly appreciated. Thanks in advance!
@epopen To clearify why you should try replicating this in a clean jail/vm: While supported, building packages in a live machine via portmaster or similar tools has become more and more problematic in the last 15 years. This is due to various reasons mostly outside of FreeBSD project control. Most upstream software defaults to building in CI environments and do not perform any check for stray dependencies or incompatibilities for potentially present software during build. So while supported, building on a live machine could take stray includes from other unrelated installed software due to filename collisions, or otherwise change behaviour due to something present in the unclean build environment. There is no way for port maintainers to foresee what other software can be present on any user machine while building, so there is no good way to test for this, and such testing has never been performed. By chance collisions with most commonly installed software are noticed earlier. But please do not provide a list of installed software, there is no way, by just looking at that, to understand what is going on. But by rebuilding all the software and nothing else in a clean environment we can see if there is a change in behaviour and the issue goes away, and have at least some evidence that the problem is of this nature. I know this is not very popular, but software should always be built in a clean environment, which is easily accomplished by using poudriere to create custom repositories. Poudriere, at present, is the easiest solution to accomplish this.
Hi @Guido Falsi I can not create clean jail right now because all of ports build in base system And copied all of require ports and theirs dependence library file into independence jail (e.g: http, mail and ftp jails) Follows your good suggestion, I shall be switch to poudriere from zero And think about how to integrate with my jail system if experience successful. Therefore I have not comment short-term. Thanks a lot.
(In reply to epopen from comment #14) While I agree with the direction you're taking, please note that without a test there is no way to be sure your problem will be solved by using poudriere. The test I'm suggesting is just a local test you can perform on any PC, no need to actually move your server. Just create a virtual machine (using bhyve or virtualbox) and in that one, build courier-imap, configuring make.conf to use ports probvided openssl, and test starting it with the same certificates you're using with the live server. This should take a few hours at most. If that works, then you will have an indication that using a clean environment could fix your issue. Changing the server configuration blindly could entail a lot of work and then ending up with the same issue.