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.
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.
Ricardo
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
