Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 3.1.0
my question is I still find myself having to use the 'intermediaries' as defined here:
however, @Osiris does not explain how to fix the situation, and bruncsak comment also does not help at all. And although alteredtech certainly helps, and @MikeMcQ confirms this, this issue is still far from solved back at freeipa-letsencrypt. Can I get a confirmation from you guys that the intermediaries are necessary as I have defined them above? Or else what should I be doing?
Ignoring the previous thread, the question seems to be around how to handle intermediate issuers certificates.
When a CA issues a certificate, they don't use their "real" root , they use an intermediate issuer that can be sacrificed at any time if a key compromise took place etc.
You (or freepia) do not need to know the intermediates, you need to trust the root and any intermediates issued by it. The intermediates can change overnight and they are included in the certificate chain when the certificate is issued, so to fix the situation your ACME tool can download that chain (often called the "fullchain").
If freeipa is doing something where it needs to "know" the intermediates then it's just plain wrong and the code needs to change to get the full chain when the certificate is downloaded.
You could keep updating it with whichever new intermediate issuers appear, but that would be the wrong thing to do and it will always break, in the future it may break much more frequently if changes to intermediates increase in frequency.
Well I am working on fixing the script, so that would be me at this point.
@orangepizza yes I am aware that they are abandoning their script, which is why I am attempting to fix it, as this is the only location I can find that details how to get LE working with FreeIPA.
@webprofusion I am aware that there is something wrong with requiring the intermediates as you have explained.
What I do not understand is why logins fail if I omit the additions of the intermediaries:
Is there something else I should be doing instead?
And I'm sorry I should be a bit more clear, the failed logins happen when I alter the httpd configs directly and have it use the certs in /etc/letsencrypt/live/example.com/, this partially works in that I do get my browser to trust ipa.example.com, however the login fails due to some issue I doubt I would be able to fix in this installation script, but is obviously related to these intermediary and/or root certs, as I do have it working when I install all of them and use ipa-server-certinstall like so:
To be honest, looking at that and then seeing the main repo of freeipa is an "integrated security management system" makes me incredibly concerned about the security of the main project.
This is why:
The code you shared references the intermediates. As @webprofusion said above:
The code you referenced uses Certbot to obtain the certificates - so it makes absolutely no sense why the intermediates are being downloaded from LetsEncrypt instead of utilizing the ones already downloaded into the certbot data store.
I will also note that file is SERIOUSLY out of date, referencing both certbot and a letsencrypt executable - which was the original name for Certbot and had changed 10+ years ago.
Certbot creates 4 files for each certificate:
privkey.pem - the private key
cert.pem - the certificate
chain.pem - the intermediates, which may vary
fullchain.pem - the cert + intermediates combined into one file
No one here can explain what is going on with your system, because we have no idea what it is doing - nor do we have the time (or any desire) to figure that out.
What we are telling you is that your system is clearly coded to recognize certain intermediates. This is an anti-pattern.
That line is an anti-pattern. It shows intermediate certificates hardcoded into the software. That should never happen.
Your code should not recognize any of these at all. If your code recognizes these (expects, looks for, changes behavior based on them, etc) it is fundamentally flawed and should be expected to break at any point in time.
The "chain.pem" file that Certbot saves will contain one or more random and continually changing intermediates, bridging the trust from the publicly trusted X1/X2 roots down the leaf certificate ("cert.pem").
All code should expect those intermediates to change with no notice. New intermediates are constantly introduced, and may be introduced with no advance notice. There is no expectation that any given intermediate will be related to any given certificate.
For whatever reasons, the do_intermediates function is trying to download several known intermediates from LetsEncrypt. That makes no sense, as intermediates can (and will) change. Also, on a quick glance the context of this appears to be downloading all the "known" intermediates and saving them into a directory for a given certificate. Aside from this being limited to known intermediates (which means the unknown intermediates, which are guaranteed to exist, can not be handled), the actual intermediates used by a given certificate exist as chain.pem in the certbot store.
The design of the software you shared is fundamentally flawed, and appears to be written from the perspective of having serious misunderstandings of the ACME protocol, Certbot's storage system, and basic TLS principles. As part of a security focused project, this makes me very concerned about the main project.
I can't stress this enough -- you are trying to fix something that is fundamentally flawed. That project should be entirely abandoned and a new solution developed from scratch.
The reference to the letsencrypt executable is only in the deprecated function that I am actively trying to rewrite, and is no longer being executed. It is merely there so I can reference it as I move forward, and will be eliminated at some point entirely once I get things working satisfactorily.
And yes the do_intermediates is the other function I am actively trying to eliminate altogether. I'm not even certain that the do_roots function should be necessary. Thank you very much for the long explanation of why I want to eleminate these things.
Root Certificates are typically only installed in Clients, not Servers.
Servers are typically only configured with Leafs and Intermediates. The Leaf is used to encrypt the content; the Intermediates are sent by the Server and used by the Client to build a path and bridge the "chain of trust" from the Leaf to the Root Certificates in the Client's Trust Store.
That's a question for the developers of your Application - I have no idea what it does.
The ca-certificates package is a Trusted Root Store managed by Fedora. If your Application integrates with that, you should usually never need to, or want to, manually insert Root Certificates. Doing that is typically only for special use cases.
the setup script doesn't install a LE certificate for web server, but make freeIPA to trust LE intermediates as CA certificate it trusts for ID management. this shouldn't never had public certificate in first place, so to install public certificate it need to install public CAs as trusted:
fails when I have not installed all the roots and the intermediaries into freeIPA's trust with:
ipa-cacert-manage install XXX.pem
I am looking for a method to elminate the intermediaries and perhaps the root installation as well, because as far as I can tell the root certificate is installed with the ca-certificates package and therefore should not need to be added to the freeipa trust as it should already be trusted.
As I understand it, please correct me. And if you have a solution please share it.
I'd say it just doesn't intended to set with any public certificate, but signed from their own CA and 'outsider' shouldn't' even touch that web panel: you run it as subCA of external CA, but it means you asking a subCA for this IdM, which LE won't do., that freeipa-letsencrypt repo was indeed a hack sacrifice internal state to work with public internet
The ssl.crt certificate must be signed by a CA known by the service you are loading the certificate into. If this is not the case, install the CA certificate of the CA that signed ssl.crt into IdM, as described in Section 26.3, “Installing a CA Certificate Manually”.
Yes, the freeIPA project is intended as a CA, but it should acknowledge the web of trust from ca-certificates. Or not, I think the LetsEncrypt team here have certainly weighed in how they feel about certificates, I eagerly await the FreeIPA teams response here:
But, I also acknowledge that you are correct, if you were using FreeIPA to be authoritative over your infrastructure it probably belongs behind the firewall with your own CA. However, I am building a publicly available demo, and I would prefer not to require users to install CA certificates in this case.
if its just a demo can you put it behind a reverse proxy (nginx/caddy etc) and let it get public certificate and let it trust self signed CA for backend?
@orangepizza I don't think this would work as freeipa is using the chain in the login process itself, hence the errors when I just switch the httpd configs to point to the LE certs. But it might. I will give that a shot at some point.
For now, I do have a working public demo until the intermediaries change I guess.
Rcritten did reply in #9802
The entire chain is required because of misunderstandings of PKI The chain is required so that IPA can be sure that the entire chain is available for clients and servers. We've seen often enough broken chains and have to dig into custom configurations to identify basic PKI issues. So we require the full chain.
The same goes for the certificates themselves. Users often follow bad formulas for generating CAs and certificates which result in invalid or non-compliant certs.
We don't impose these restrictions arbitrarily but because we've been shown over and over how they can be abused.
This is less likely with a CA like LE which has its roots shipped in most OS's so is already trusted. It is custom PKI that generates the problems.