FreeIPA-users November 2021

freeipa-users@lists.fedorahosted.org

45 participants
76 discussions

Certificate Authority master cert shows revoked somehow (refresh issue due bad hosts file?)
by Andrius Jurkus 02 Dec '21

02 Dec '21

ipa --version VERSION: 4.8.7 So I have no idea what actually happened, but today I cant login into freeipa webui. There is 3 instances on 2 and 3rd I can login. Sync is on and working. I noticed that in webui it shows that first certificate CN=Certificate Authority,O=xx ipa REVOKED Obviously I didint revoke it. ipa-getcert list shows only two certificates and noone is master getcert list shows more and this is master cert as you can see server was installed ~2 years ago. Request ID '20201218102240': 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=xxx subject: CN=Certificate Authority,O=xxx expires: 2039-12-16 13:38:03 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 CN=localhost... :facepalm: This is I guess new(not really) and probably this was tickint time bomb for quite some time. Request ID '20210317111052': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca bd372c7d-62d0-469d-a107-da3b5a782c09',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca bd372c7d-62d0-469d-a107-da3b5a782c09',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=INT.O4.LT subject: CN=localhost expires: 2041-03-17 11:11:01 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign profile: caCACert pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca bd372c7d-62d0-469d-a107-da3b5a782c09" track: yes auto-renew: yes I have bad feeling that it is because hosts file is not cleared from localhost entries? cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 ipa-healthcheck complainas about this is SUBCA caSigningCert cert-pki-ca 86623fac-5d11-4ac6-9972-ea80ef16f711 not found, assuming 3rd party { "source": "ipahealthcheck.ipa.certs", "check": "IPACertfileExpirationCheck", "result": "ERROR", "uuid": "a77e06d1-ee90-4574-8c68-750ec3f5d6bd", "when": "20211124184538Z", "duration": "0.366900", "kw": { "key": "20210317111052", "dbdir": "/etc/pki/pki-tomcat/alias", "nickname": "caSigningCert cert-pki-ca bd372c7d-62d0-469d-a107-da3b5a782c09", "error": "Failed to get caSigningCert cert-pki-ca bd372c7d-62d0-469d-a107-da3b5a782c09", "msg": "Unable to retrieve cert 'caSigningCert cert-pki-ca bd372c7d-62d0-469d-a107-da3b5a782c09' from '/etc/pki/pki-tomcat/alias': Failed to get caSigningCert cert-pki-ca bd372c7d-62d0-469d-a107-da3b5a782c09" } }, { "source": "ipahealthcheck.ipa.certs", "check": "IPACertTracking", "result": "ERROR", "uuid": "c8e78e6d-794c-41cb-a12f-f57d0dda23d6", "when": "20211124184538Z", "duration": "0.416846", "kw": { "key": "cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent, cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad, cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert \"caSigningCer t cert-pki-ca\", template-profile=caCACert", "msg": "Missing tracking for cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent, cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad, cert-postsave-command=/usr/libexec/ipa/certmonger/renew_c a_cert \"caSigningCert cert-pki-ca\", template-profile=caCACert" } }, and more question how I can fix this?

2 4

Another pki-tomcatd failing to start due to expired certs
by Jacob Block 01 Dec '21

01 Dec '21

Hi all, I have read through pretty much every thread on this topic and unfortunately will be starting a new one. I am trying to upgrade an older IPA server that has had all the cert-pki-ca certs expired. Some other history, the initial master used to be on a VPS and was moved on-site several years ago by spinning up a replica on-site, promoting it to the new master, and shutting down the master. I am not entirely convinced there wasn't some issue also before the expired certs. There is also no other replica. I'd like to get this working, create a replica, and start upgrading to the latest. # ipa --version VERSION: 4.6.4, API_VERSION: 2.230 # getcert list Number of certificates and requests being tracked: 9. Request ID '20190405192115': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IPA-COMPANY-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-COMPANY-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IPA-COMPANY-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IPA.COMPANY.COM subject: CN=ipa.internal.company.com,O=IPA.COMPANY.COM expires: 2023-03-09 22:30:53 UTC dns: ipa.internal.company.com principal name: ldap/ipa.internal.company.com(a)IPA.COMPANY.COM key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IPA-COMPANY-COM track: yes auto-renew: yes Request ID '20190405192140': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IPA.COMPANY.COM subject: CN=ipa.internal.company.com,O=IPA.COMPANY.COM expires: 2023-03-09 22:31:53 UTC dns: ipa.internal.company.com principal name: HTTP/ipa.internal.company.com(a)IPA.COMPANY.COM key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_httpd track: yes auto-renew: yes Request ID '20190405192207': status: NEED_GUIDANCE stuck: yes 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=IPA.COMPANY.COM subject: CN=IPA RA,O=IPA.COMPANY.COM expires: 2021-09-05 16:48:11 UTC key usage: digitalSignature,nonRepudiation,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 '20190405192208': 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=IPA.COMPANY.COM subject: CN=ipa.internal.company.com,O=IPA.COMPANY.COM expires: 2023-03-09 22:30:44 UTC principal name: krbtgt/IPA.COMPANY.COM(a)IPA.COMPANY.COM 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 '20190405204557': status: NEED_GUIDANCE stuck: yes 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=IPA.COMPANY.COM subject: CN=CA Audit,O=IPA.COMPANY.COM expires: 2021-09-05 16:48:31 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 '20190405204558': status: GENERATING_CSR 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=IPA.COMPANY.COM subject: CN=OCSP Subsystem,O=IPA.COMPANY.COM expires: 2021-09-05 16:49:41 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 '20190405204559': status: NEED_GUIDANCE stuck: yes 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=IPA.COMPANY.COM subject: CN=CA Subsystem,O=IPA.COMPANY.COM expires: 2021-09-05 16:48:21 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,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 '20190405204600': 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=IPA.COMPANY.COM subject: CN=Certificate Authority,O=IPA.COMPANY.COM expires: 2041-09-01 05:41:44 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 '20190405204601': 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=IPA.COMPANY.COM subject: CN=ipa.internal.company.com,O=IPA.COMPANY.COM expires: 2023-02-15 22:30:43 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth,id-kp-emailProtection 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 The renewal master used to be the remote VPS master that no longer exists. I've since updated that: # ipa config-show | grep renewal IPA CA renewal master: ipa.internal.company.com One thing I am confused by is seeing four entries for "caSigningCert cert-pki-ca" (I also have a tenuous understanding of CAs and certs) # certutil -L -d /var/lib/pki/pki-tomcat/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu DSTRootCAX3 C,, CN=R3,O=Let's Encrypt,C=US C,, CN=E1,O=Let's Encrypt,C=US C,, auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu caSigningCert cert-pki-ca CTu,Cu,Cu caSigningCert cert-pki-ca CTu,Cu,Cu ISRGRootCAX3 C,, ISRGRootCAX3 C,, ISRGRootCAX1 C,, CN=ISRG Root X2,O=Internet Security Research Group,C=US C,, CN=R4,O=Let's Encrypt,C=US C,, CN=E2,O=Let's Encrypt,C=US C,, I've tried rolling back the clock to before 2021-09-05 but pki-tomcatd still doesn't start: Jun 01 05:15:44 ipa.internal.company.com server[919212]: CMSEngine.initializePasswordStore() begins Jun 01 05:15:44 ipa.internal.company.com server[919212]: CMSEngine.initializePasswordStore(): tag=internaldb Jun 01 05:15:44 ipa.internal.company.com server[919212]: CMSEngine.initializePasswordStore(): tag=replicationdb Jun 01 05:15:45 ipa.internal.company.com server[919212]: Internal Database Error encountered: Could not connect to LDAP server host ipa.internal.company.com port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8172) Peer's certificate issuer has been marked as not trusted by the user. (-1) Jun 01 05:15:55 ipa.internal.company.com server[919212]: WARNING: Exception processing realm com.netscape.cms.tomcat.ProxyRealm@70aacdbc background process Jun 01 05:15:55 ipa.internal.company.com server[919212]: javax.ws.rs.ServiceUnavailableException: Subsystem unavailable Jun 01 05:15:55 ipa.internal.company.com server[919212]: at com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) Jun 01 05:15:55 ipa.internal.company.com server[919212]: at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) Jun 01 05:15:55 ipa.internal.company.com server[919212]: at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) Jun 01 05:15:55 ipa.internal.company.com server[919212]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) Jun 01 05:15:55 ipa.internal.company.com server[919212]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) Jun 01 05:15:55 ipa.internal.company.com server[919212]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) Jun 01 05:15:55 ipa.internal.company.com server[919212]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520) Jun 01 05:15:55 ipa.internal.company.com server[919212]: at java.lang.Thread.run(Thread.java:748) Maybe its pki certs + https certs are both having a problem? Maybe this is related to a recent LE CA? Any thoughts would be greatly appreciated. Thank you!

3 3

EMC Isilon and IPA - Kerberos
by thing.thing＠gmail.com 30 Nov '21

30 Nov '21

I have the Isilon talking to IPA for LDAP. What I cannot yet do is run the Isilon command to make kerberos work. ===== tststocoiso-1# kinit admin(a)ODSTEST.VUWTEST.AC.NZ Password for admin(a)ODSTEST.VUWTEST.AC.NZ: tststocoiso-1# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin(a)ODSTEST.VUWTEST.AC.NZ Valid starting Expires Service principal 11/30/21 16:44:56 12/01/21 16:10:10 krbtgt/ODSTEST.VUWTEST.AC.NZ(a)ODSTEST.VUWTEST.AC.NZ tststocoiso-1# isi auth krb5 spn fix --provider-name=ODSTEST.VUWTEST.AC.NZ --user=admin password: Attempting to add missing SPNs: HTTP/tststocoisnfs01.odstest.vuwtest.ac.nz(a)ODSTEST.VUWTEST.AC.NZ hdfs/tststocoisnfs01.odstest.vuwtest.ac.nz(a)ODSTEST.VUWTEST.AC.NZ host/tststocoisnfs01.odstest.vuwtest.ac.nz(a)ODSTEST.VUWTEST.AC.NZ nfs/tststocoisnfs01.odstest.vuwtest.ac.nz(a)ODSTEST.VUWTEST.AC.NZ Failed to join realm: (LW_ERROR_KADM5_AUTH_ADD) Operation requires ``add'' privilege tststocoiso-1# ==== What is the add privilege? how do I grant it to admin? TY.

3 2

Re: FreeIPA letsencrypt certificate problems after recent expiration of DST Root CA X3
by Rob Crittenden 30 Nov '21

30 Nov '21

TDH Innovation CDH Mailbox via FreeIPA-users wrote: > Dear Stephan, > > > thanks for your reply. > > > We are facing a similar issue (on cloudera CDH) and I wanted to ask you > > how you >> removed the expired X3 CA and cross-signed X1 with > `ipa-cacert-manage` (using the force flag), > > I do not see force flag in my v. (4.6.4) of the command... The delete option was added in IPA 4.9.0. You'd need to remove any certificates using an ldap editor or ldapmodify/ldapdelete. The DN is going to look something like: cn=SOME SUBJECT NAME,cn=certificates,cn=ipa,cn=etc,dc=example,dc=test Just be careful, this is dealing with some IPA internals and you could easily shoot yourself in the foot. I'd recommend saving off a copy of the entry before trying to remove it so you can restore it if something goes wrong. Or snapshot your install. Or both. rob

1 0

Re: Revert web cert from 3rd party to internal ca
by Rob Crittenden 30 Nov '21

30 Nov '21

No because all the clients already trust and know the IPA CA. Glad you got it working. rob Dungan, Scott A. wrote: > Thanks, Rob. > > That worked. Does changing the web certs on the ipa servers require a ' ipa-certupdate' on all clients afterward? As far as I can tell, everything appears to be working normally without it. > > -Scott > > -----Original Message----- > From: Rob Crittenden <rcritten(a)redhat.com> > Sent: Monday, November 29, 2021 10:59 AM > To: Dungan, Scott A. <sdungan(a)caltech.edu>; FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > Subject: Re: [Freeipa-users] Revert web cert from 3rd party to internal ca > > Dungan, Scott A. wrote: >> Rob, >> >> I don't think my response was sent correctly, so sending it again-apologies for any duplicates. Also, for misspelling your name. >> >> >> >> Bob, >> >> I ran the command on the first IPA server (idm1) as: >> >> ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k >> /var/lib/ipa/private/httpd.key -p >> /var/lib/ipa/passwds/$HOSTNAME-443-RSA -D idm1.xxx.xxx.edu -D >> idm1.xxx.xxx.edu -C /usr/libexec/ipa/certmonger/restart_httpd -K >> HTTP/idm1.xxx.xxx.edu -v -w >> >> It appears the command did not change the HTTP certificate on the IdM server. The time stamps and content of /var/lib/ipa/certs/httpd.crt and /var/lib/ipa/private/httpd.key are unchanged. Rather, the commercial cert is now tracked by certmonger?: >> >> ~]# getcert list >> >> .... >> Request ID '20211119173141': >> status: MONITORING >> stuck: no >> key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key',pinfile='/var/lib/ipa/passwds/xxx.xxx.xxx.edu-443-RSA' >> certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt' >> CA: IPA >> issuer: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US >> subject: CN=idm1.xxx.xxx.edu,OU=GPS,O=xxx,STREET=xxx,L=xxx,ST=xxx,postalCode=xxx,C=xxx >> expires: 2022-01-02 15:59:59 PST >> dns: idm1.xxx.xxx.edu >> key usage: digitalSignature,keyEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/libexec/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> I was expecting that the HTTP service on idm1 would get a new cert from the IPA self-signed CA, and then that would be tracked/renewed by certmonger. Certmonger will be unable to auto-renew the commercial cert, so tracking that is not useful. > > certmonger was too clever by half. It saw that the current cert is valid so went ahead and tracked it instead of requesting a replacement. > > You can stop the tracking with getcert stop-tracking -i 20211119173141 > > Then backup /var/lib/ipa/private/httpd.key and /var/lib/ipa/certs/httpd.crt, just in case. > > If you then remove /var/lib/ipa/certs/httpd.crt and re-run the request command it will generate a new CSR using the existing key and an IPA should issue a replacement cert. You'll need to restart Apache afterward. > > rob > >> >> -Scott >> >> -----Original Message----- >> From: Rob Crittenden <rcritten(a)redhat.com> >> Sent: Monday, November 15, 2021 11:04 AM >> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >> Cc: Dungan, Scott A. <sdungan(a)caltech.edu> >> Subject: Re: [Freeipa-users] Revert web cert from 3rd party to >> internal ca >> >> Dungan, Scott A. via FreeIPA-users wrote: >>> Hi All >>> >>> >>> >>> After deploying FreeIPA with an embedded self-signed CA, the ipa >>> servers were configured to use commercially signed, 3^rd party >>> certificates for the HTTP service only. The directory server was left >>> default. This was accomplished by importing the external CA and then >>> the signed certificate, following the instructions on freeipa.org: >>> >>> >>> >>> ipa-cacert-manage -t C,, install InCommon_interm.cer >>> >>> ipa-certupdate >>> >>> ipa-server-certinstall --http /var/lib/ipa/private/httpd.key >>> /var/lib/ipa/private/InCommon_signed.cer >>> >>> ipactl restart >>> >>> >>> >>> A commercially signed web certificate on the ipa servers is no longer >>> required and we would like to revert back to using certificates from >>> the freeipa self-signed CA. Is there a way to do so? >> >> This will request a new certificate using certmonger which will replace the 3rd party certificate and configure the renewal tracking. You may want to make a copy of the 3rd party cert and key just in case. >> >> ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k >> /var/lib/ipa/private/httpd.key -p >> /var/lib/ipa/passwds/ipa.example.test-443-RSA -D `hostname` -D >> ipa-ca.example.test -C /usr/libexec/ipa/certmonger/restart_httpd -K >> HTTP/`hostname` -v -w >> >> If you aren't using ACME you can skip the SAN for ipa-ca.example.test >> >> Restart the httpd service once it is issued. >> >> Adjust to your hostname/domain as needed. >> >> rob >> >

1 0

Re: Revert web cert from 3rd party to internal ca
by Rob Crittenden 30 Nov '21

30 Nov '21

Dungan, Scott A. wrote: > Rob, > > I don't think my response was sent correctly, so sending it again-apologies for any duplicates. Also, for misspelling your name. > > > > Bob, > > I ran the command on the first IPA server (idm1) as: > > ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/$HOSTNAME-443-RSA -D idm1.xxx.xxx.edu -D idm1.xxx.xxx.edu -C /usr/libexec/ipa/certmonger/restart_httpd -K HTTP/idm1.xxx.xxx.edu -v -w > > It appears the command did not change the HTTP certificate on the IdM server. The time stamps and content of /var/lib/ipa/certs/httpd.crt and /var/lib/ipa/private/httpd.key are unchanged. Rather, the commercial cert is now tracked by certmonger?: > > ~]# getcert list > > .... > Request ID '20211119173141': > status: MONITORING > stuck: no > key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key',pinfile='/var/lib/ipa/passwds/xxx.xxx.xxx.edu-443-RSA' > certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt' > CA: IPA > issuer: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US > subject: CN=idm1.xxx.xxx.edu,OU=GPS,O=xxx,STREET=xxx,L=xxx,ST=xxx,postalCode=xxx,C=xxx > expires: 2022-01-02 15:59:59 PST > dns: idm1.xxx.xxx.edu > key usage: digitalSignature,keyEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > I was expecting that the HTTP service on idm1 would get a new cert from the IPA self-signed CA, and then that would be tracked/renewed by certmonger. Certmonger will be unable to auto-renew the commercial cert, so tracking that is not useful. certmonger was too clever by half. It saw that the current cert is valid so went ahead and tracked it instead of requesting a replacement. You can stop the tracking with getcert stop-tracking -i 20211119173141 Then backup /var/lib/ipa/private/httpd.key and /var/lib/ipa/certs/httpd.crt, just in case. If you then remove /var/lib/ipa/certs/httpd.crt and re-run the request command it will generate a new CSR using the existing key and an IPA should issue a replacement cert. You'll need to restart Apache afterward. rob > > -Scott > > -----Original Message----- > From: Rob Crittenden <rcritten(a)redhat.com> > Sent: Monday, November 15, 2021 11:04 AM > To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > Cc: Dungan, Scott A. <sdungan(a)caltech.edu> > Subject: Re: [Freeipa-users] Revert web cert from 3rd party to internal ca > > Dungan, Scott A. via FreeIPA-users wrote: >> Hi All >> >> >> >> After deploying FreeIPA with an embedded self-signed CA, the ipa >> servers were configured to use commercially signed, 3^rd party >> certificates for the HTTP service only. The directory server was left >> default. This was accomplished by importing the external CA and then >> the signed certificate, following the instructions on freeipa.org: >> >> >> >> ipa-cacert-manage -t C,, install InCommon_interm.cer >> >> ipa-certupdate >> >> ipa-server-certinstall --http /var/lib/ipa/private/httpd.key >> /var/lib/ipa/private/InCommon_signed.cer >> >> ipactl restart >> >> >> >> A commercially signed web certificate on the ipa servers is no longer >> required and we would like to revert back to using certificates from >> the freeipa self-signed CA. Is there a way to do so? > > This will request a new certificate using certmonger which will replace the 3rd party certificate and configure the renewal tracking. You may want to make a copy of the 3rd party cert and key just in case. > > ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/ipa.example.test-443-RSA -D `hostname` -D ipa-ca.example.test -C /usr/libexec/ipa/certmonger/restart_httpd -K HTTP/`hostname` -v -w > > If you aren't using ACME you can skip the SAN for ipa-ca.example.test > > Restart the httpd service once it is issued. > > Adjust to your hostname/domain as needed. > > rob >

2 1

Re: FreeIPA letsencrypt certificate problems after recent expiration of DST Root CA X3
by TDH Innovation CDH Mailbox 30 Nov '21

30 Nov '21

Dear Stephan, thanks for your reply. We are facing a similar issue (on cloudera CDH) and I wanted to ask you how you > removed the expired X3 CA and cross-signed X1 with `ipa-cacert-manage` (using the force flag), I do not see force flag in my v. (4.6.4) of the command... thanks for your help, Gr

1 0

set homedir to /home/%u to AD user with FreeIPA
by Jan Poctavek 30 Nov '21

30 Nov '21

Hi, Maybe I'm just missing something very trivial but I have trouble setting user homedirs to a value of /home/%u instead of default /home/%d/%u for users from AD (with established one-way trust). We have AD server example.com and FreeIPA on idm-eu.example.com. Ubuntu clients are joined to IPA without issues. The only way I've achieved to change the homedir destination was to use following statement in sssd.conf: override_homedir = /home/%u But with override_homedir all idview homedir overrides are ignored and this is a problem for us. I've tried playing with fallback_homedir and subdomain_homedir but without any success (no change after sss_cache -E && systemctl restart sssd && getent passwd myaduser1). It still points to /home/example.com/myaduser1 (or to value of idview override). What can I do to use custom default homedir path and to utilize idview homedir overrides at the same time? IPA server is on Centos8: ipa-common-4.9.3-1 Ubuntu is on 20.04: # ipa --version VERSION: 4.8.6, API_VERSION: 2.236 Thank you. Jan

3 2

Python ipalib
by Ronald Wimmer 30 Nov '21

30 Nov '21

When I started writing python scripts communicating with the IPA API some years ago I used the python-freeipa library (https://python-freeipa.readthedocs.io/en/latest/ ). When I revisited one of my scripts today I was wondering why I was using python-freeipa and not ipalib that comes with every freeipa-client installation. My guess is that ipalib is the way to go because it comes directly from you. Is there any good reason for sticking with python-freeipa? (I doubt it...) What are your thoughts? Cheers, Ronald

3 7

Re: Revert web cert from 3rd party to internal ca
by Rob Crittenden 29 Nov '21

29 Nov '21

Dungan, Scott A. via FreeIPA-users wrote: > Hi All > > > > After deploying FreeIPA with an embedded self-signed CA, the ipa servers > were configured to use commercially signed, 3^rd party certificates for > the HTTP service only. The directory server was left default. This was > accomplished by importing the external CA and then the signed > certificate, following the instructions on freeipa.org: > > > > ipa-cacert-manage -t C,, install InCommon_interm.cer > > ipa-certupdate > > ipa-server-certinstall --http /var/lib/ipa/private/httpd.key > /var/lib/ipa/private/InCommon_signed.cer > > ipactl restart > > > > A commercially signed web certificate on the ipa servers is no longer > required and we would like to revert back to using certificates from the > freeipa self-signed CA. Is there a way to do so? This will request a new certificate using certmonger which will replace the 3rd party certificate and configure the renewal tracking. You may want to make a copy of the 3rd party cert and key just in case. ipa-getcert request -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/ipa.example.test-443-RSA -D `hostname` -D ipa-ca.example.test -C /usr/libexec/ipa/certmonger/restart_httpd -K HTTP/`hostname` -v -w If you aren't using ACME you can skip the SAN for ipa-ca.example.test Restart the httpd service once it is issued. Adjust to your hostname/domain as needed. rob

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users November 2021