[Freeipa-users] Re: FreeIPA behind Traefik Reverse Proxy, with wildcard certs
I am seeing the "SSL Library Error: - 12271 SSL client cannot verify your certificate "in /var/log/httpd/error_log" every time I try to access the webui. When I go to the web address auth.ethanlambert.info it just shows a blank page with the text "Internal Server Error" The reverse proxy is so that I can have one vm/machine per service, I like the idea of self hosting my stuff and I would like single sign on for each app so photos.ethanlambert.info, docs.ethanlambert.info, etc. and from what I understand the easiest way to do that is a reverse proxy. I will read the article and see what I can figure out from it. Thanks! ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/ZYKGXT54X6MIBFOVFGYG4FB5JQFJLDVT/
[Freeipa-users] Re: Changing domain name
Alfredo De Luca via FreeIPA-users wrote:
> Hi Rob.
> Yes. I am following the link you sent. So now I can understand they need
> to create the new Kerberos but given the command I should have seen all
> the users in the new freeipa server... which are not there.
> Maybe I put a wrong command? (below)
>
> ipa migrate-ds --bind-dn="cn=Directory Manager"
> --user-container=cn=users,cn=accounts --group-overwrite-gid
> --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup
> --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference,mepManagedEntry}
> --user-ignore-objectclass=mepOriginEntry --with-compat
> ldap://192.168.20.177:389
>
> Password:
> ---
> migrate-ds:
> ---
> Migrated:
> group: admins, editors
> Failed user:
> admin: This entry already exists
> Failed group:
> --
> Passwords have been migrated in pre-hashed format.
> IPA is unable to generate Kerberos keys unless provided
> with clear text passwords. All migrated users need to
> login at https://your.domain/ipa/migration/ before they
> can use their Kerberos accounts.
It isn't finding any of your users. Are you sure that IP address points
to your existing IPA instance?
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/57LEZBOJFBXNAZLE5NGLJKJ7YWALICZT/
[Freeipa-users] Re: FreeIPA behind Traefik Reverse Proxy, with wildcard certs
Ethan Lambert via FreeIPA-users wrote: > I have FreeIPA running in a VM with a static IP assigned via dnsmasq with > Traefik acting as a reverse proxy. I have traefik grabbing wildcard certs for > the domain. However, it seems that FreeIPA does not like that as it has this > error in the error log: > > `SSL Library Error: - 12271 SSL client cannot verify your certificate` > > I assume this is because the wildcard cert for the domain > (example.com/*.example.com) is not the cert that FreeIPA is expecting? Doubtful. We need more context. Where are you seeing this, the web UI, command-line, client enrollment? You are likely to also run into referrer issues. The IPA master(s) will need to verify that the Referrer in the request points to them. Can you explain why you need a reverse proxy? You should read https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > > When I try to access the web interface it returns: "Internal Server Error" > and adds another entry of "SSL Library Error: = 12271 SSL client cannot > verify your certificate" > > What should I do to fix this, there is the CA-less install ( > https://www.freeipa.org/page/V3/CA-less_install ) > > However that wants a long list of Certs (http_pkcs12, dirsrv_pkcs12, etc) and > wants those at install, do I just have to reinstall? Will doing a CA-less > install even fix my problem? This has nothing to with the IPA CA (or lack-thereof). 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CNF3TBZWNZFHHRS46DMF7L45KL6DQF3J/
[Freeipa-users] Re: Changing domain name
Alfredo De Luca via FreeIPA-users wrote: > Hi Florence. Thanks again. I understand about the password hash... but > does it mean all the users need to do that before migration? or after? > > Cause in the new ipa server can 't see any of the users/groups. Then I assume the migration failed? I believe there is a chapter in the RHEL docs on migration and it is also mentioned at https://www.freeipa.org/page/Howto/Migration Users will need to re-authenticate themselves post-migration in order to set their Kerberos credentials. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/EVHJCOOEE7RTQUJTJIPIHQCQA2UL5KJV/
[Freeipa-users] Problem with pki-tomcatd starting on 1 of 3 systems after upgrade from 4.2.0 to 4.5.4
Hello, I’m hoping somebody here can help with an issue I’m having with upgrades and ipaca. I have (3) CentOS 7.1.1503 based systems that I’m trying to upgrade from 4.2.0-15.0.1.el7 to ipa-server-4.5.4-10.el7. I’m able to upgrade the “second master” (dirsrv, DNS, ipaca backup) and “third master” (dirsrv, DNS, apace backup) without an issue (replication is good after 3-4 hours). But when I try to upgrade the “first master” (dirsrv, DNS, ipaca primary) the upgrade process completes successfully and starts the services, but the pki-tomcat fails to stay running. Odd thing is that it does run for about 4-5 minutes (I can see certificate data, and can list certificates from the CLI), but after about 5 minutes the whole IPA system stops (per the systemctl). I can run the IPA services on the “first master” (ipactl start --ignore-service-failures), but eventually the replication for ipaca fails — I suppose this is expected since pki-tomcat isn’t running (LDAP connection error from the “first master” to the “second/third masters”). Funny thing is I’m not able to see anything in the logs that point to anything that shows as a fault. In referencing https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/, I wasn’t able to isolate anything that seems like it was related to the issue of pki-tomcatd terminating. I eventually reverted all hosts back to a “safe snapshot” and reverted to keep the production systems active and in sync. I’m hoping the wise people here might be able to ID something amiss in the currently running systems before I make another attempt to get the systems upgraded again, or perhaps suggest superset of logs and data-points I would need to gather if it was to fail again. Per https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/ — /var/log/ipaupgrade.log: Completed successfully /var/log/pki/pki-tomcat/ca/debug: No trace/stack outputs. No strings marked as “error”. Also checked catalina.out, and didn’t see anything amiss. There was a trace for a missing module (can’t remember the name right now and it isn’t in my notes), but the services and webapps started without it. Certificate cert-pki-ca: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' | grep 'Not' Not Before: Sun Aug 20 22:02:05 2017 Not After : Sat Aug 10 22:02:05 2019 sudo certutil -L -d /etc/dirsrv/slapd---COM/ -n Server-Cert |grep "Not " Not Before: Thu Aug 31 22:02:18 2017 Not After : Sun Sep 01 22:02:18 2019 sudo certutil -L -d /etc/httpd/alias/ -n Server-Cert |grep "Not " Not Before: Thu Aug 31 22:02:08 2017 Not After : Sun Sep 01 22:02:08 2019 Was able to read cert using the password in /var/lib/pki/pki-tomcat/conf/password.conf. In LDAP uid=pkidbuser,ou=people,o=ipaca userCertificate appears to be valid and matches what is in the NSSDB. There are (8) certificates being monitored, and none have expired — sudo getcert list Number of certificates and requests being tracked: 8. Request ID '20150928161427': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd---COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd---COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd---COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=..COM subject: CN=starfleet...com,O=..COM expires: 2019-09-01 22:02:18 UTC principal name: ldap/starfleet...com@..COM key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv --COM track: yes auto-renew: yes Request ID '20150928161756': 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=..COM subject: CN=starfleet...com,O=..COM expires: 2019-09-01 22:02:08 UTC principal name: HTTP/starfleet...com@..COM key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command:
