@Jamie, why are we using the SSLCACertificateFile directive to provide the intermediate certificate to clients!? That directive is meant only for client certificate authentication, not for serving intermediates.
Besides, we don’t need to include the intermediate certificate these days, and definitely not via SSLCACertificateFile. Older Apache versions used SSLCertificateChainFile, but modern ones (version 2.4.8 and up) expect both the certificate and the chain to be in SSLCertificateFile, like in ssl.combined.
We definitely need to fix this!
If anyone is seeing this issue, just remove those directives by running:
sudo find /etc/apache2 /etc/httpd -type f -name '*.conf' 2>/dev/null -exec sed -i '/^[[:space:]]*SSLCACertificateFile/d' {} +
No, we need separate topics about completely unrelated issues. Apache obviously cannot have anything to do with Dovecot. Make a new topic for your Dovecot issue.
Jamie, here is what we should do, in my perspective to make things work correctly.
We do not set SSLCertificateChainFile at all, if we already have set or can set ssl.combined for SSLCertificateFile.
If we don’t and SSLCertificateFile is already set to ssl.cert only, we should set SSLCertificateChainFile which will work perfectly fine on old and new Apache.
Some users reported that they don’t have SSLCertificateFile set to ssl.combined.
I dug into all this more, and surprisingly, the SSLCACertificateFile directive, even though it’s meant for client auth, still works well for serving intermediate certificates, just like SSLCertificateChainFile.
@Joe, and now, I don’t understand the fuss around it. Yes, it’s recommended to use SSLCertificateFile with ssl.combined, but either SSLCertificateChainFile or the currently incorrectly used SSLCACertificateFile works fine with ssl.ca on multiple distros I tried.
Can anyone reading this provide useful analytical info? What isn’t working and when? What settings do you have in the Apache config when it works and when it doesn’t? Please don’t just say it doesn’t work or it stopped working after an upgrade—it’s not really helpful.
While testing this on a number of different distros, I found another serious bug where Apache breaks configs when SSL for the host domain fails, and it’s 100% reproducible on my Debian 12 local instance. I think the Webmin Apache API isn’t meant to handle adding and deleting a domain in the same call. This is the only part of the code that does it.
@Jamie, I’m looking into fixing it right now, but can you make sure we’re not setting either SSLCACertificateFile or SSLCertificateChainFile and instead just use SSLCertificateFile with ssl.combined? I think we should remove both of those unnecessary directives and make sire we handle this properly during restore as well—agreed?
If we do need to set a CA file for manually installed certificates, then it should definitely be SSLCertificateChainFile, not SSLCACertificateFile—agreed?
Well, in this case, it’s necessary because SSLCertificateChainFile doesn’t reference the interm CA cert in the ssl.cert file, ssl.combined does. So, some clients like curl will refuse to work correctly. As the Apache documentation clearly states that:
SSLCertificateChainFile became obsolete with version 2.4.8, when SSLCertificateFile was extended to also load intermediate CA certificates from the server certificate file.
This means ideally we shouldn’t use either SSLCertificateChainFile or SSLCACertificatePath. But I assume Jamie just picked it as a quick fix over old SSLCertificateChainFile code logic.
The latest patches still use the SSLCACertificatePath directive, meaning they use all three ssl.cert, ssl.key, and ssl.ca for ACME providers. I assume changing it without potentially breaking anything won’t be straightforward. So, we should probably just leave it as is.
@Jamie, the only confusing thing about the current code is that the self-signed certificate is generated with ssl.combined rather than ssl.cert. Is this intentional? Because later, in the LE request, it’s replaced with ssl.cert for SSLCertificateFile.
To clarify for any future readers — we’re currently using SSLCACertificatePath to provide the interm CA cert, similar to how SSLCertificateChainFile was used in the past.
It’s a bit confusing since the main purpose of SSLCACertificatePath is for client-cert auth trust, but according to the Apache documentation, it can also be used to send interm CA as we’re doing now.