[Freeipa-users] Re: Why is ipa-ods-exporter broken after running ipa-dns-install? (Was - Unable to start directory server after updates)
Last week I ran the command: > [root@utility ~]# ipa-certupdate > > cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) > The ipa-certupdate command failed. We tested the root CA cert and server cert. Both were found to be good. Is it possible I'd need to chain the two together? Which certificate is the error message complaining about? What directory? Update-ca-trust had no affect. Is this because of the above error message? From: Jeremy Tourville Sent: Friday, September 10, 2021 3:41 PM To: FreeIPA users list Cc: Florence Renaud ; Rob Crittenden Subject: Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after running ipa-dns-install? (Was - Unable to start directory server after updates) ACK, the typo was why certutil failed initially. It works now. >>>So update-ca-trust had no affect or was this run beforehand? Update-ca-trust had no affect. it was run after doing the ipa-cacert-mange renew . >>>You didn't happen to touch /etc/httpd/conf.d/ssl.conf did you? No, I left it alone >>>This renews the CA certificate. The CA is good for 20 years, you didn't need to do this. ACK >>>We now have another CA certificate for IPA in the mix because of the renewal. OK, I'll stand by so I don't really mess it up. From: Rob Crittenden Sent: Friday, September 10, 2021 3:26 PM To: FreeIPA users list Cc: Florence Renaud ; Jeremy Tourville Subject: Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after running ipa-dns-install? (Was - Unable to start directory server after updates) Jeremy Tourville via FreeIPA-users wrote: > I was doing some reading and troubleshooting > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/cert-renewal#manual-cert-renewal > > which basically says: > #1 ipa-cacert-manage renew > #2 ipa-certupdate > #3 certutil -L -d /etc/pki/pki-tomcat/alias (to test the certs) > > See my output. Step #1 and #3 work now but #2 still fails > > > [root@utility certs]# ipa-certupdate > > cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) > The ipa-certupdate command failed. So update-ca-trust had no affect or was this run beforehand? > [root@utility certs]# certutil -L -d /etc/pki/pik-tomcat/alias > > certutil: function failed: SEC_ERROR_BAD_DATABASE: security library: bad > database. It failed because of a typo, pik -> pki. > [root@utility certs]# ipa-cacert-manage renew > > Renewing CA certificate, please wait > CA certificate successfully renewed > The ipa-cacert-manage command was successful This renews the CA certificate. The CA is good for 20 years, you didn't need to do this. > [root@utility certs]# ipa-certupdate > > cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) > The ipa-certupdate command failed. We now have another CA certificate for IPA in the mix because of the renewal. > > [root@utility certs]# certutil -L -d /etc/pki/pki-tomcat/alias > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > ocspSigningCert cert-pki-ca u,u,u > subsystemCert cert-pki-cau,u,u > auditSigningCert cert-pki-ca u,u,Pu > Server-Cert cert-pki-ca u,u,u > caSigningCert cert-pki-caCTu,Cu,Cu > IDM.NAC-ISSA.ORG IPA CA CTu,Cu,Cu > [root@utility certs]# reboot It isn't a problem with the CA. The system doesn't trust the CA for some reason, though the openssl command verified that it is ok. > [root@utility certs]# reboot > > [root@utility ~]# ipa-certupdate > > cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) > The ipa-certupdate command failed. You didn't happen to touch /etc/httpd/conf.d/ssl.conf did you? rob > > [root@utility ~]# ipactl status > > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > httpd Service: RUNNING > ipa-custodia Service: RUNNING > pki-tomcatd Service: RUNNING > smb Service: RUNNING > winbind Service: RUNNING > ipa-otpd Service: RUNNING > ipa-ods-exporter Service: STOPPED > ods-enforcerd Service: RUNNING > ipa-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > > *From:* Rob Crittenden > *Sent:* Friday, September 10, 2021 9:49 AM > *To:* Jeremy Tourville ; FreeIPA users > list > *Cc:* Florence Renaud > *Subject:* Re: [Freeipa-users] Re: Why is
[Freeipa-users] Re: ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck - Request ID expires in....
Thank you! It resolved itself before I got a chance to try resubmitting the ID's. :-) On Mon, Sep 13, 2021 at 9:17 AM Rob Crittenden wrote: > Russell Jones via FreeIPA-users wrote: > > Hi all, > > > > I am not sure what to do with these below errors. Are they related to my > > failed replica that I rebuilt and resynced, and as a result can be > > ignored? All the current certificates seem to be healthy. > > According to ipa-healthcheck they will be healthy for the next 27 days. > > These messages are a heads-up that renewal is imminent and if you don't > see it happen then you may need to take some manual action to figure out > why, so you don't end up in a world of hurt. > > You could pick one and run getcert resubmit -i to see if it gets a > new certificate. > > journalctl -u certmonger will tell you what certmonger is doing. > > rob > > > > > Thanks for the insight! > > > > > > WARNING: > > ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160502: > > Request id 20191010160502 expires in 27 days > > WARNING: > > ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160533: > > Request id 20191010160533 expires in 27 days > > WARNING: > > ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160542: > > Request id 20191010160542 expires in 27 days > > WARNING: > > ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160502: > > Request id 20191010160502 expires in 27 days > > WARNING: > > ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160533: > > Request id 20191010160533 expires in 27 days > > WARNING: > > ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160542: > > Request id 20191010160542 expires in 27 days > > > > > > [root@freeipa ~]# getcert list | grep -i status > > status: MONITORING > > status: MONITORING > > status: MONITORING > > status: MONITORING > > status: MONITORING > > status: MONITORING > > status: MONITORING > > status: MONITORING > > status: MONITORING > > > > ___ > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > To unsubscribe send an email to > freeipa-users-le...@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.fedorahosted.org > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: [Freeipa-users] ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck - Request ID expires in....
Russell Jones via FreeIPA-users wrote: > Hi all, > > I am not sure what to do with these below errors. Are they related to my > failed replica that I rebuilt and resynced, and as a result can be > ignored? All the current certificates seem to be healthy. According to ipa-healthcheck they will be healthy for the next 27 days. These messages are a heads-up that renewal is imminent and if you don't see it happen then you may need to take some manual action to figure out why, so you don't end up in a world of hurt. You could pick one and run getcert resubmit -i to see if it gets a new certificate. journalctl -u certmonger will tell you what certmonger is doing. rob > > Thanks for the insight! > > > WARNING: > ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160502: > Request id 20191010160502 expires in 27 days > WARNING: > ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160533: > Request id 20191010160533 expires in 27 days > WARNING: > ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160542: > Request id 20191010160542 expires in 27 days > WARNING: > ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160502: > Request id 20191010160502 expires in 27 days > WARNING: > ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160533: > Request id 20191010160533 expires in 27 days > WARNING: > ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160542: > Request id 20191010160542 expires in 27 days > > > [root@freeipa ~]# getcert list | grep -i status > status: MONITORING > status: MONITORING > status: MONITORING > status: MONITORING > status: MONITORING > status: MONITORING > status: MONITORING > status: MONITORING > status: MONITORING > > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck - Request ID expires in....
Hi all, I am not sure what to do with these below errors. Are they related to my failed replica that I rebuilt and resynced, and as a result can be ignored? All the current certificates seem to be healthy. Thanks for the insight! WARNING: ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160502: Request id 20191010160502 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160533: Request id 20191010160533 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160542: Request id 20191010160542 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160502: Request id 20191010160502 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160533: Request id 20191010160533 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160542: Request id 20191010160542 expires in 27 days [root@freeipa ~]# getcert list | grep -i status status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Waiting for CA subsystem to start (round 2)
For records that works if I remove these lines in /etc/crypto-policies/back-ends/nss.config name=p11-kit-proxy library=p11-kit-proxy.so ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] [BUG?] Host Alias DNS
Hello, I'm trying to provision an HTTP service principal for a containerized service. The host on which the container is running also has a kerberized HTTP service running on it with a separate service principal (both services are highly critical, but for different systems, and thus should probably have separate keytabs). Since both services share an IP address (but are serving HTTP on different ports), this seemed like a perfect application of kerberos host aliases. However, when I provisioned a host alias with `ipa host-add-principal myHost host/myAlias.domain.com`, I found that on DNS records were provisioned for `myAlias.domain.com`, thus making the alias completely useless for resolving to the container. Is this a bug in the host-alias system, or am I missing something? Thank you for your time. Thank you, Buckley Ross ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Add second SSL to host
Hi Rob The SAN would also work really well since we are only using subdomains and hardly ever a new domain. I tried the following: ipa-getcert resubmit -D HTTP/sub2.example.com -i 20210910082436 But when I check ipa-getcert lis it says: ca-error: Server at https://ipaserver.example.com/ipa/json denied our request, giving up: 3009 (invalid 'csr': hostname in subject of request 'sub1.example.com' does not match name or aliases of principal 'HTTP/sub2.example@example.com'). I have added ipa service-add HTTP/sub2.example.com before running the command and a A record is in the DNS for sub2.example.com I am pretty sure that i am not understanding something or missing a step but what am I missing? Regards Per On 9 September 2021 at 19:49, Rob Crittenden wrote: Per Qvindesland via FreeIPA-users wrote: Hi I am using the IPA server as the CA for our Apache SSL's, but I am wondering if it's possible to have a second SSL that's not the same as the hostname, meaning I have already sub1.mydomain.com but I would like to add also sub2.mydomain.com for another site, is this possible? I have tried adding the hostname so ipa host-add sub2.mydomain.com then ipa service-add HTTP/sub2.mydomain.com, but when I do: ipa-getcert request -K HTTP/sub2.mydomain.com -k /ssl/sub2.mydomaincom.key -f /ssl/sub2.mydomain.com.csr -N sub2.mydomain.com then ipa-getcert list says it fails with: status: CA_REJECTED ca-error: Server at https://ipaserver.mydomain.com/ipa/json denied our request, giving up: 2100 (Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'krbprincipalname=HTTP/sub2.mydomain@mydomain.com,cn=services,cn=accounts,dc=mydomain,dc=com'.) How can I resolve this? certmonger (ipa-getcert) uses the credentials in /etc/krb5.conf on the machine to authentication. By default it can only request certificates for its own hostname. You can use ipa service-add-host to add the host to the new service name. Additionally, do you need a completely separate certificate or do you want to add a SAN to the existing one? To do that you'd run: ipa-getcert resubmit -D HTTP/your_new_hostname -i rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: CA errors after update, server.xml desync?
I ran into similar issues after upgrading from FreeIPA 4.9.3 to 4.9.6 on Centos Stream 8 last week. You could check /var/log/httpd/error_log - I had trouble with TLS 1.3 (leading to error "Request failed with status 403: Non-2xx response from CA REST API: 403.") which could be solved by disabling SSLProtocol in /etc/httpd/conf.d/ssl.conf. There were other issues with disabling TLS 1.3 (see https://bugzilla.redhat.com/show_bug.cgi?id=1775158) and due to lack of time, finally I recovered from backup. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
