Ricardo Mendes wrote:
Hi Rob thanks for your message.
> Right the cert nickname is CN=main.domain.io. I'm assuming you manually
installed the LE certs originally using ipa-server-certinstall right?
> That doesn't follow the pattern of using Server-Cert for the nickname by
default.
Iirc I used the antevens/letsencrypt-freeipa script to first install LE
certs. My issue with these scripts has been that they never renew
automatically and this has caused my issues in the past, but I was able
to fix it more simply, this time around I'm struggling a bit more. I
don't know if it was due to version changes but probably I guess.
> You can probably just hack the LE script and replace Server-Cert with
CN=main.domain.io.
I was looking to try this but I can't find "Server-Cert" in the LE
script. The LE script has the setup-le.sh: installs letsencrypt/certbot,
installs DSTRootCAX3.pem and LetsEncryptAuthorityX3.pem and calls
"renew-le.sh".
Renew checks the dates, makes a cleanup, generates csr, gets a new
certificate, replaces it and restarts httpd.
So in these scripts (on github freeipa repo, freeipa-letsencrypt) I
don't see a place to replace "Server-Cert". Can you please give me a
hint where to look for that "Server-Cert" validation and where to hack it?
Today I ran the renew-le.sh script again (the one from 2017). I got this
error in the end:
ipaplatform.redhat.tasks: INFO: Systemwide CA database updated.
ipalib.backend: DEBUG: Destroyed connection
context.rpcclient_140348868817552
ipapython.admintool: INFO: The ipa-certupdate command was successful
Error opening Private Key /var/lib/ipa/private/httpd.key
140615547713424:error:02001002:system library:fopen:No such file or
directory:bss_file.c:402:fopen('/var/lib/ipa/private/httpd.key','r')
140615547713424:error:20074002:BIO routines:FILE_CTRL:system
lib:bss_file.c:404:
unable to load Private Key
Looking at /var/lib/ipa, these are the directories:
# ls -la /var/lib/ipa
total 48
drwxr-xr-x. 9 root root 4096 Apr 2 14:40 .
drwxr-xr-x. 45 root root 4096 May 25 2020 ..
drwxr-xr-x. 2 root root 4096 May 26 2020 auth_backup
drwx------. 4 root root 4096 Apr 2 14:40 backup
-rw-------. 1 root root 1196 May 16 00:32 ca.csr
drwxrwx---. 3 ods named 4096 Feb 20 2019 dnssec
drwx------. 2 root root 4096 Apr 2 14:40 gssproxy
drwxr-xr-x. 3 root root 4096 Apr 2 14:40 pki-ca
-r--r-----. 1 root ipaapi 1704 Feb 20 2019 ra-agent.key
-r--r-----. 1 root ipaapi 1229 Feb 20 2019 ra-agent.pem
drwx--x--x. 2 root root 4096 Apr 2 14:40 sysrestore
drwx------. 2 root root 4096 Apr 2 14:40 sysupgrade
There is no "private" folder.
You must have restored your git repo to HEAD. As I said before, the
current HEAD does not work against anything < IPA 4.7.something.
You need to get to the commit before "Move from mod_nss to mod_ssl"
Then you'll see Server-Cert in renew-le.sh.
rob
> It's important to know that the LE script was written specifically for
the IPA demo site and a repo created to share the general method. It
isn't shipped with IPA or otherwise really supported at all. No
backwards compatibility testing is done, just what is needed for the
demo site. So while it might eventually work fine for you it isn't
intended to be a general-purpose tool.
> rob
It is important to know thanks, I actually thought it was more used.
People use LE across a number of applications and websites, and having
this as functional would be interesting as prevents the errors thrown by
self-signed certs, and I didn't thought it was unsupported at all, on
the contrary really. It would be nice if it was tended a little. For
example the script on the repo has dnf, but yum is still used on red hat
and CentOS. a simple validator for yum or dnf would also be nice and its
an easy thing to implement. But well just a thought, thanks, I will have
to think about using a proper certificate after fixing this.
We don't normally just dump code but it's a specific script for the
demo. It seemed generally useful so it was shared.
It has no branches and only supports that latest release of IPA that the
demo runs.
There are no plans to generalize or package it. You're free to tackle it
if you'd like and include it in EPEL, for example.
rob