Ricardo Mendes via FreeIPA-users wrote:
I think you need to see what certs and keys are in /etc/httpd/alias. Sounds like there is no Server-Cert nickname.
certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
This is the output, and I'm adding getcert list in the end as well.
# certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
DSTRootCAX3 C,, CN=main.domain.io u,u,u letsencryptx3 C,, letsencryptx3 C,, ISRGRootCAX1 C,, DOMAIN.IO IPA CA CT,C,
# certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" < 0> rsa 493a92843c598413e3f50ca923706417821bf392 CN=main.domain.io < 1> rsa e946257bb7a486f489287ccd72dab14067eae2b7 CN=main.domain.io < 2> rsa 8bbe08dd006063eea896aee19f24da6b5f28f348 CN=main.domain.io < 3> rsa ac96e477d65db3ba63213332c30ac7733bf70a10 (orphan) < 4> rsa b40bea3d28cce1ea7274f8ecf47b2d70f5e0c0c1 CN=main.domain.io #
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.
You can probably just hack the LE script and replace Server-Cert with CN=main.domain.io.
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
# getcert list Number of certificates and requests being tracked: 7. Request ID '20190220114014': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' CA: IPA issuer: CN=Certificate Authority,O=DOMAIN.IO subject: CN=main.domain.io,O=DOMAIN.IO expires: 2021-02-20 11:40:16 UTC principal name: krbtgt/DOMAIN.IO@DOMAIN.IO key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-pkinit-KPKdc pre-save command: post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert track: yes auto-renew: yes Request ID '20190819230939': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.IO subject: CN=CA Audit,O=DOMAIN.IO expires: 2021-02-09 11:36:51 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190819230940': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.IO subject: CN=OCSP Subsystem,O=DOMAIN.IO expires: 2021-02-09 11:36:48 UTC eku: id-kp-OCSPSigning pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190819230941': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.IO subject: CN=CA Subsystem,O=DOMAIN.IO expires: 2021-02-09 11:36:50 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190819230942': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.IO subject: CN=Certificate Authority,O=DOMAIN.IO expires: 2039-02-20 11:36:43 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190819230943': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key' certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.IO subject: CN=IPA RA,O=DOMAIN.IO expires: 2021-02-09 11:37:44 UTC key usage: digitalSignature,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20190819230944': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.IO subject: CN=main.domain.io,O=DOMAIN.IO expires: 2021-02-09 11:36:49 UTC dns: main.domain.io key usage: digitalSignature,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca" track: yes auto-renew: yes
(btw https://lists.fedoraproject.org is down)
Related to the Fedora infrastructure move.
hope all is going well!
Ricardo _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste...
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@lists.fedorahosted.org