# Freeipa-letsencrypt **URL:** \ **Category:** Help\ **Created:** [May 30, 2025, 4:17am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966 "2025-05-30T04:17:27Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [May 30, 2025, 4:17am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/1 "2025-05-30T04:17:27Z")
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](https://crt.sh/?q=example.com)), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help. My domain is: [resolve.deploycoop.com](http://resolve.deploycoop.com) I ran this command: ./setup-le.sh from this project: > **[GitHub - freeipa/freeipa-letsencrypt: A quick hack allowing to use Let's Encrypt...](https://github.com/freeipa/freeipa-letsencrypt)** > > A quick hack allowing to use Let's Encrypt certificates for FreeIPA web interface. And I am trying to fix this problem: > [@Freeipa doesn't see the full certificate chain when CN = E6](https://community.letsencrypt.org/t/freeipa-doesnt-see-the-full-certificate-chain-when-cn-e6/220278): > > H… The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you're using Certbot): ```nohighlight 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? ---
**Author:** ![webprofusion](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/webprofusion/32/85310_2.png) [@webprofusion](https://community.letsencrypt.org/u/webprofusion)\ **Post date:** [May 30, 2025, 4:52am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/2 "2025-05-30T04:52:29Z")
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. ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [May 30, 2025, 5:28am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/3 "2025-05-30T05:28:30Z")
repo writer themselves abandoned this script: > > > We lack time to spend on determining the best way to retrieve the > LE chain and i…mport it into IPA automatically. The current hardcoding > of the chain has gone from bad to worse such that multiple people > have broken systems. > > This is no longer used by the demo team so warn new users against using > it. > > Signed-off-by: Rob Crittenden \ ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [May 30, 2025, 5:36am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/4 "2025-05-30T05:36:03Z")
> [@joshuacox](#): > > however, @Osiris does not explain how to fix the situation That's because that's the job of the developers of that script. ---
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [May 30, 2025, 3:08pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/5 "2025-05-30T15:08:19Z")
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? ---
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [May 30, 2025, 3:39pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/6 "2025-05-30T15:39:42Z")
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](http://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: ```nohighlight ipa-server-certinstall \ -w \ --dirman-password="${DIRMAN_PASSWORD}" \ -d /etc/letsencrypt/live/${FQDN}/privkey.pem /etc/letsencrypt/live/$FQDN/fullchain.pem \ --pin='' ``` This command fails if I do not install the intermediary certs. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [May 30, 2025, 4:21pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/7 "2025-05-30T16:21:10Z")
> [@joshuacox](#): > > Is there something else I should be doing instead? 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: > [@webprofusion](#): > > 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. 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. ``` CERTS2=("e5.pem" "e6.pem" "e7.pem" "e8.pem" "e9.pem" "r10.pem" "r11.pem" "r12.pem" "r13.pem" "r14.pem") ``` 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. So, going back to what @webprofusion said above: > [@webprofusion](#): > > 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. 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. ---
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [May 30, 2025, 7:15pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/8 "2025-05-30T19:15:25Z")
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. ---
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [May 30, 2025, 10:22pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/9 "2025-05-30T22:22:50Z")
And should the root certificates need installing? I think they are already present anyhow: ```nohighlight ls -alh /etc/pki/ca-trust/extracted/pem/directory-hash|grep -i isrg lrwxrwxrwx. 1 root root 59 May 30 15:15 0b9bc432.0 -> CN_ISRG_Root_X2_O_Internet_Security_Research_Group_C_US.pem lrwxrwxrwx. 1 root root 59 May 30 15:15 4042bcee.0 -> CN_ISRG_Root_X1_O_Internet_Security_Research_Group_C_US.pem lrwxrwxrwx. 1 root root 59 May 30 15:15 6187b673.0 -> CN_ISRG_Root_X1_O_Internet_Security_Research_Group_C_US.pem lrwxrwxrwx. 1 root root 59 May 30 15:15 8794b4e3.0 -> CN_ISRG_Root_X2_O_Internet_Security_Research_Group_C_US.pem -r--r--r--. 1 root root 1.9K May 30 15:15 CN_ISRG_Root_X1_O_Internet_Security_Research_Group_C_US.pem -r--r--r--. 1 root root 790 May 30 15:15 CN_ISRG_Root_X2_O_Internet_Security_Research_Group_C_US.pem ``` I opened an issue with the FreeIPA folks directly as well: [https://pagure.io/freeipa/issue/9802](https://pagure.io/freeipa/issue/9802) ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [May 30, 2025, 10:46pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/10 "2025-05-30T22:46:46Z")
> [@joshuacox](#): > > And should the root certificates need installing? 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. ---
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [May 31, 2025, 3:05pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/11 "2025-05-31T15:05:36Z")
@jvanasco By "installl" I mean specifically ```nohighlight ipa-cacert-manage install XXX.pem ``` However, I believe that both servers and clients will have the file: ```nohighlight /etc/pki/ca-trust/extracted/pem/directory-hash/CN_ISRG_Root_X1_O_Internet_Security_Research_Group_C_US.pem ``` installed by the ca-certificates package in fedora, and therefore the above ipa-cacert-manage command seems unnecessary. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [May 31, 2025, 3:31pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/12 "2025-05-31T15:31:24Z")
> [@joshuacox](#): > > By "installl" I mean specifically > > ```nohighlight > ipa-cacert-manage install XXX.pem > > ``` That's a question for the developers of your Application - I have no idea what it does. > [@joshuacox](#): > > installed by the ca-certificates package in fedora 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. ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [May 31, 2025, 8:34pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/13 "2025-05-31T20:34:51Z")
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: > **[ipa-cacert-manage: Manage CA certificates in IPA | freeipa-server Commands |...](https://www.mankier.com/1/ipa-cacert-manage)** > > ipa-cacert-manage can be used to manage CA certificates in IPA. > **[26.6. Installing Third-Party Certificates for HTTP or LDAP | Linux...](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/third-party-certs-http-ldap)** > > 26.6. Installing Third-Party Certificates for HTTP or LDAP | Linux Domain Identity, Authentication, and Policy Guide | Red Hat Enterprise Linux | 7 | Red Hat Documentation ---
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [June 1, 2025, 12:04am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/14 "2025-06-01T00:04:41Z")
@orangepizza yes the problem I am having is that the command: ```nohighlight ipa-server-certinstall \ -w \ --dirman-password="${DIRMAN_PASSWORD}" \ -d /etc/letsencrypt/live/${FQDN}/privkey.pem /etc/letsencrypt/live/$FQDN/fullchain.pem \ --pin='' ``` fails when I have not installed all the roots and the intermediaries into freeIPA's trust with: ```nohighlight 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. ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [June 1, 2025, 12:43am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/15 "2025-06-01T00:43:45Z")
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”](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/manual-cert-install). old question on freeipa git for same thing > > > Hi Team, > > I've been trying to set up letsencrypt with your FreeIPA but its get…ting failed when I run ipa-certupdate > > Can you update your FreeIPA project with letsencrypt like --setup-ca with letsencrypt ? ---
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [June 2, 2025, 1:55am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/16 "2025-06-02T01:55:37Z")
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: > **[Issue #9802: ipa-server-certinstall requires letsencrypt intermediaries -...](https://pagure.io/freeipa/issue/9802)** 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. ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [June 2, 2025, 2:01am UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/17 "2025-06-02T02:01:15Z")
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? ---
**Author:** ![joshuacox](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/joshuacox/32/87639_2.png) [@joshuacox](https://community.letsencrypt.org/u/joshuacox)\ **Post date:** [June 4, 2025, 3:41pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/18 "2025-06-04T15:41:37Z")
@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. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [July 4, 2025, 3:42pm UTC](https://community.letsencrypt.org/t/freeipa-letsencrypt/237966/19 "2025-07-04T15:42:20Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.