I have the same problem. I’m running Mojave.
Followed instructions from letsencrypt to add new cert to keychain. Couldn’t
find an old one to remove though and the problem remains.
I found the error when trying to enable a bundle, and it wouldn’t stick, but no
error came up. I checked for updates and found the cert error. I since
downloaded bundle from GitHub, and added to mailmate package manually, seems to
have worked.
I guess a similar workaround to just download any new version of MailMate
manually, but that is a bit of a pain. Especially for a whole office. Any help
to resolve would be great.
Thanks.
--
Seamus Phillips
(+44)7905521930
seamus.phill...@gmail.com
> On 25 Nov 2021, at 00:45, Randall Gellens <mailm...@randy.pensive.org> wrote:
>
> On 12 Nov 2021, at 12:22, Bill Cole wrote:
>
>> On 2021-11-12 at 13:34:46 UTC-0500 (Fri, 12 Nov 2021 10:34:46 -0800)
>> Randall Gellens <mailmate@lists.freron.com>
>> is rumored to have said:
>>
>>> I just tried to check for an update but received the error "SSL certificate
>>> problem: certificate has expired", which might explain why I wasn't aware
>>> there was anything newer.
>>
>> That's probably a consequence of the recent expiration of the root CA cert
>> ("DST Root CA X3") on a secondary validation path for Let's Encrypt
>> certificates. Sites serve the full trust chain of certs needed for all of
>> their trust paths except for the root to all clients and many are still
>> serving both the valid trust path and the one that relies on an expired
>> root. There's actually no consensus on whether server and intermediate certs
>> that were issued when a CA cert was valid should be considered invalid when
>> the CA expires but the issued cert is still nominally valid.
>>
>> The fixes for that base problem vary between systems and can be confusing
>> because an app can use the OS's security layer and its keychains of trusted
>> CA certs or the Apple-distributed antique OpenSSL with a PEM bundle of CA
>> certs in /etc/ssl/cert.pem or the MacPorts OpenSSL with the
>> 'curl-ca-bundle' package that puts a link at /opt/local/etc/openssl/cert.pem
>> which points to /opt/local/share/curl/curl-ca-bundle.crt. Or if you use
>> Homebrew, you might have something in /usr/local/etc. Some apps may even
>> bundle their own SSL libraries to do self-updates. I'm pretty sure MM just
>> uses the system facilities, but if you have similar problems with other tools
>>
>> If Keychain Access will let you do so, you should remove "DST Root CA X3"
>> from your System Roots keychain.
>> On recent systems with SPI enabled, you can't do that so you can work around
>> the problem by changing its Trust Settings to "Always Trust."
>
> I don't seem to have such a certificate. Nothing matches "DST" or "X3"
> anywhere.
>
>
>> You also should check your keychains for multiple versions of the "ISRG Root
>> X1" certificate, which SHOULD be a self-signed root CA cert in SystemRoots.
>> However, you may also have another version in the System or login keychains
>> which is NOT actually a root CA cert but rather is issued by that expired
>> root CA cert. If you do have one of those, they need to go. If you are
>> unable to remove non-root versions of the "ISRG Root X1" cert or do not have
>> the root version in SystemRoots, you can get the current version from
>> http://x1.i.lencr.org/ and import it into your System keychain. (imports
>> into SystemRoots don't work.)
>
> I only have one such certificate, which expires in 2035. Serial number "00
> 82 10 CF B0 D2 40 E3 59 44 63 E0 BB 63 82 8B 00".
>
>
> Given that I don't seem to have a "DST Root CA X3" cert and I have only one
> "ISRG Root X1" cert, what do you suggest?
> _______________________________________________
> mailmate mailing list
> mailmate@lists.freron.com
> https://lists.freron.com/listinfo/mailmate
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate
