[Freeipa-users] CA-less replica setup and trouble with cert chain
Hi folks, We're trying to add a FreeIPA (4.1; CentOS 7) replica to our infrastructure and keep running into an issue that prevents us from preparing the replica. We're using the CA-less setup where FreeIPA is using a wildcard certificate provided by RapidSSL. I started trying to create the replica using the information provided here : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html But since we're not using a CA, it tells me that I need to specify --http-cert-file and --dirsrv-cert-file. I create a p12 file that includes the wildcard cert and the rest of the certs in the chain with: $ openssl pkcs12 -export -in wildcard-with-intermediates.crt -inkey wildcard.key -name replica01 -out replica01.mydomain.com.p12 I then check to see if all the necessary certs were added to the p12 file: $ pk12util -l replica01.mydomain.com.p12 I see our wildcard certificate, RapidSSL's intermediate certificate, and the entry for Equifax/GeoTrust, that signed RapidSSL's certificate. Then I run 'ipa-replica-prepare' on the existing FreeIPA server. $ ipa-replica-prepare replica01.mydomain.com \ --http-cert-file=replica01.mydomain.com.p12 \ --dirsrv-cert-file=replica01.mydomain.com.p12 \ --ca /etc/ipa/ca.crt \ -v I get the following error after the debug output reports a series of calls to certutil: ipa: DEBUG: stderr= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 169, in execute self.ask_for_options() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 262, in ask_for_options options.http_cert_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 162, in load_pkcs12 host_name=self.replica_fqdn) File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 799, in load_pkcs12 (, .join(cert_files))) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: ScriptError: The full certificate chain is not present in replica01.mydomain.com.p12 ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: The full certificate chain is not present in replicate01.mydomain.com.p12 The chain certainly looks to be complete given the output of pk12util, but it's possible I'm just building the file wrong for use with FreeIPA. What exactly is '--http-cert-file' and '--dirsrv-cert-file' expecting and how should I go about generating the certificate used by 'ipa-replica-prepare' with a CA-less configuration? Thanks all, -- Mike Oliver -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] bind-dynamicdb TKEY update
Hola! So with todays advisory: https://kb.isc.org/article/AA-01272 we finally get to test the procedure to patch and update here :) Are there any plans for the dynamic_db github to pull in the fix, or should I proceed with that step? Sincerely, Lund -- Jorgen Lundman | lund...@lundman.net Unix Administrator | +81 (0)90-5578-8500 (work) Shibuya-ku, Tokyo| +81 (0)80-2090-5800 (cell) Japan| +81 (0)3 -3375-1767 (home) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] bind-dynamicdb TKEY update
Took a look at the diff while I was waiting:
diff -rub bind-9.9.7-P1/lib/dns/tkey.c bind-9.9.7-P2/lib/dns/tkey.c
--- bind-9.9.7-P1/lib/dns/tkey.c2015-06-18 07:48:03.0 +0900
+++ bind-9.9.7-P2/lib/dns/tkey.c2015-07-15 08:50:22.0 +0900
@@ -650,6 +650,7 @@
* Try the answer section, since that's where Win2000
* puts it.
*/
+ name = NULL;
if (dns_message_findname(msg, DNS_SECTION_ANSWER, qname,
dns_rdatatype_tkey, 0, name,
tkeyset) != ISC_R_SUCCESS) {
Sigh. All that work for one line. :)
Lund
Jorgen Lundman wrote:
Hola!
So with todays advisory: https://kb.isc.org/article/AA-01272
we finally get to test the procedure to patch and update here :)
Are there any plans for the dynamic_db github to pull in the fix, or should
I proceed with that step?
Sincerely,
Lund
--
Jorgen Lundman | lund...@lundman.net
Unix Administrator | +81 (0)90-5578-8500 (work)
Shibuya-ku, Tokyo| +81 (0)80-2090-5800 (cell)
Japan| +81 (0)3 -3375-1767 (home)
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] CA-less replica setup and trouble with cert chain
Hi, Dne 29.7.2015 v 00:56 Mike Oliver napsal(a): Hi folks, We're trying to add a FreeIPA (4.1; CentOS 7) replica to our infrastructure and keep running into an issue that prevents us from preparing the replica. We're using the CA-less setup where FreeIPA is using a wildcard certificate provided by RapidSSL. I started trying to create the replica using the information provided here : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html But since we're not using a CA, it tells me that I need to specify --http-cert-file and --dirsrv-cert-file. I create a p12 file that includes the wildcard cert and the rest of the certs in the chain with: $ openssl pkcs12 -export -in wildcard-with-intermediates.crt -inkey wildcard.key -name replica01 -out replica01.mydomain.com.p12 I then check to see if all the necessary certs were added to the p12 file: $ pk12util -l replica01.mydomain.com.p12 I see our wildcard certificate, RapidSSL's intermediate certificate, and the entry for Equifax/GeoTrust, that signed RapidSSL's certificate. Then I run 'ipa-replica-prepare' on the existing FreeIPA server. $ ipa-replica-prepare replica01.mydomain.com \ --http-cert-file=replica01.mydomain.com.p12 \ --dirsrv-cert-file=replica01.mydomain.com.p12 \ --ca /etc/ipa/ca.crt \ -v Note that you can use the .crt and .key files directly: $ ipa-replica-prepare replica01.mydomain.com --http-cert-file=wildcard-with-intermediates.crt --http-cert-file=wildcard.key --dirsrv-cert-file=wildcard-with-intermediates.crt --dirsrv-cert-file=wildcard.key I get the following error after the debug output reports a series of calls to certutil: ipa: DEBUG: stderr= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 169, in execute self.ask_for_options() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 262, in ask_for_options options.http_cert_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 162, in load_pkcs12 host_name=self.replica_fqdn) File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 799, in load_pkcs12 (, .join(cert_files))) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: ScriptError: The full certificate chain is not present in replica01.mydomain.com.p12 ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: The full certificate chain is not present in replicate01.mydomain.com.p12 The chain certainly looks to be complete given the output of pk12util, but it's possible I'm just building the file wrong for use with FreeIPA. What exactly is '--http-cert-file' and '--dirsrv-cert-file' expecting and how should I go about generating the certificate used by 'ipa-replica-prepare' with a CA-less configuration? If the chain is complete, there should be a self-signed CA certificate at the top. For you that would be the Equifax/GeoTrust certificate. If it's not self-signed, it means the chain is in fact not complete. Thanks all, Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare error
Dne 20.7.2015 v 19:52 Orion Poplawski napsal(a): On 07/20/2015 12:57 AM, Jan Cholasta wrote: Dne 15.7.2015 v 20:57 Orion Poplawski napsal(a): On 07/14/2015 11:53 PM, Jan Cholasta wrote: # ipa-replica-prepare -v ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX Directory Manager (existing master) password: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Not much :( Seems to be very early. I can't find an ipa-replica-prepare.log file. That's weird, there should be ~50 lines of output before ipa-replica-prepare prompts you for directory manager password. I didn't have any luck in reproducing the issue so far. Could you please try this: $ mkdir tmpdb $ certutil -N -d tmpdb $ pk12util -i nwra.com.p12 $ certutil -L -d tmpdb # look for nickname of certificate which has trust attributes of u,u,u $ certutil -O -d tmpdb -n nickname # use the nickname from above I would like to see the output of the last 2 commands. [root@europa ~]# pk12util -i nwra.com.p12 -d tmpdb Enter Password or Pin for NSS Certificate DB: Enter password for PKCS12 file: pk12util: no nickname for cert in PKCS12 file. pk12util: using nickname: *.nwra.com - COMODO CA Limited pk12util: PKCS12 IMPORT SUCCESSFUL [root@europa ~]# certutil -L -d tmpdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI COMODO RSA Domain Validation Secure Server CA - COMODO CA Limited ,, AddTrust External CA Root - AddTrust AB ,, *.nwra.com - COMODO CA Limited u,u,u COMODO RSA Certification Authority - AddTrust AB ,, [root@europa ~]# certutil -O -d tmpdb -n '*.nwra.com - COMODO CA Limited' AddTrust External CA Root - AddTrust AB [CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE] COMODO RSA Certification Authority - AddTrust AB [CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB] COMODO RSA Domain Validation Secure Server CA - COMODO CA Limited [CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB] *.nwra.com - COMODO CA Limited [CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Validated] Thanks. Unfortunately it looks perfectly fine, so I still have no idea what's wrong. This is a long shot, but coult you try running ipa-replica-prepare in strace and post the log of that? # strace -o ipa-replica-prepare-strace.log ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Kerberos hanging approx. once a day
Dear Rich, all, Am 28.07.15 um 19:08 schrieb Rich Megginson: # ldapsearch -xLLL -D cn=directory manager -W -s base -b dc=uni-wuppertal,dc=de [...] real0m4.559s user0m0.403s sys 0m0.057s [root@ipa httpd]# Looks okay to us, or? 4 seconds? That seems way too long. No.. that includes the time it took me to enter the password. Only the user line is relevant, so 0.4 seconds. So.. here is the problem which is left over. When logging in as admin now through th web page or locally: [Thu Jul 23 21:43:47.340133 2015] [wsgi:error] [pid 1134] ipa: INFO: [jsonserver_session] wens...@pleiades.uni-wuppertal.de: radiusproxy_find(None, version=u'2.114'): SUCCESS [Thu Jul 23 21:43:48.758849 2015] [wsgi:error] [pid 1133] ipa: INFO: [jsonserver_session] wens...@pleiades.uni-wuppertal.de: user_find(None, version=u'2.114'): SUCCESS [Fri Jul 24 07:20:10.198903 2015] [wsgi:error] [pid 1134] ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while getting initial credentials [Fri Jul 24 07:20:10.198977 2015] [wsgi:error] [pid 1134] [Fri Jul 24 07:20:18.181715 2015] [wsgi:error] [pid 1133] ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while getting initial credentials [Fri Jul 24 07:20:18.181809 2015] [wsgi:error] [pid 1133] [Fri Jul 24 07:21:12.919751 2015] [wsgi:error] [pid 1134] ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while getting initial credentials [Fri Jul 24 07:21:12.919878 2015] [wsgi:error] [pid 1134] [root@ipa httpd]# kinit admin kinit: Clients credentials have been revoked while getting initial credentials [root@ipa httpd]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: ad...@pleiades.uni-wuppertal.de Valid starting Expires Service principal 07/23/2015 11:44:13 07/24/2015 11:44:08 HTTP/ipa.pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de 07/23/2015 11:44:11 07/24/2015 11:44:08 krbtgt/pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de [root@ipa httpd]# Hope you have an idea about that one as well :). I do not, sorry. Maybe one of our kerberos experts will know. Hope so.. the problem still persists. Strangely, it's not always there. And it's only on the primary, not on the secondary server. with an strace there is a difference when it does NOT work: keyctl(KEYCTL_GET_PERSISTENT, 0, KEY_SPEC_PROCESS_KEYRING) = 294917837 keyctl(KEYCTL_SEARCH, 294917837, keyring, _krb, KEY_SPEC_PROCESS_KEYRING) = 780102244 keyctl(KEYCTL_SEARCH, 780102244, user, krb_ccache:primary, 0) = 12049273 keyctl(KEYCTL_READ, 12049273, NULL, 0) = 10 keyctl(KEYCTL_READ, 12049273, , 10) = 10 keyctl(KEYCTL_READ, 780102244, NULL, 0) = 4 keyctl(KEYCTL_READ, 780102244, y\333\267, 4) = 4 keyctl(KEYCTL_SEARCH, 780102244, keyring, 0, 0) = -1 ENOKEY (Required key not available) keyctl(KEYCTL_DESCRIBE, 12049273, NULL, 0) = 37 keyctl(KEYCTL_DESCRIBE, 12049273, user;0;0;3f01;krb_ccache:pri..., 37) = 37 compared to when it WORKS: keyctl(KEYCTL_GET_PERSISTENT, 0, KEY_SPEC_PROCESS_KEYRING) = 294917837 keyctl(KEYCTL_SEARCH, 294917837, keyring, _krb, KEY_SPEC_PROCESS_KEYRING) = 780102244 keyctl(KEYCTL_SEARCH, 780102244, user, krb_ccache:primary, 0) = 12049273 keyctl(KEYCTL_READ, 12049273, NULL, 0) = 10 keyctl(KEYCTL_READ, 12049273, , 10) = 10 keyctl(KEYCTL_SEARCH, 780102244, keyring, 0, 0) = 17381009 keyctl(KEYCTL_SEARCH, 17381009, user, __krb5_princ__, 0) = 378086918 keyctl(KEYCTL_SEARCH, 17381009, user, __krb5_time_offsets__, 0) = 416824569 keyctl(KEYCTL_READ, 416824569, NULL, 0) = 8 keyctl(KEYCTL_READ, 416824569, , 8) = 8 keyctl(KEYCTL_READ, 378086918, NULL, 0) = 46 keyctl(KEYCTL_READ, 378086918, , 46) = 46 keyctl(KEYCTL_GET_PERSISTENT, 0, KEY_SPEC_PROCESS_KEYRING) = 294917837 keyctl(KEYCTL_SEARCH, 294917837, keyring, _krb, KEY_SPEC_PROCESS_KEYRING) = 780102244 keyctl(KEYCTL_SEARCH, 780102244, user, krb_ccache:primary, 0) = 12049273 keyctl(KEYCTL_READ, 12049273, NULL, 0) = 10 keyctl(KEYCTL_READ, 12049273, , 10) = 10 keyctl(KEYCTL_READ, 780102244, NULL, 0) = 12 keyctl(KEYCTL_READ, 780102244, y\333\267, 12) = 12 keyctl(KEYCTL_SEARCH, 780102244, keyring, 0, 0) = 17381009 keyctl(KEYCTL_SEARCH, 17381009, user, __krb5_princ__, 0) = 378086918 keyctl(KEYCTL_READ, 378086918, NULL, 0) = 46 keyctl(KEYCTL_READ, 378086918, , 46) = 46 Best regards Torsten -- Dr. Torsten Harenberg harenb...@physik.uni-wuppertal.de Bergische Universitaet FB C - Physik Tel.: +49 (0)202 439-3521 Gaussstr. 20 Fax : +49 (0)202 439-2811 42097 Wuppertal Of course it runs NetBSD http://www.netbsd.org -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Kerberos hanging approx. once a day
On 07/24/2015 01:20 AM, Torsten Harenberg wrote: Dear Rich and all, thanks to everbody! Really thankful for your support. The situation really approved. We: - enlarged the caches for 389ds until the WARNING messages disappeared in the log files, - (just to be sure) re-sync'ed firewalld rules between primary and secondary server. Now the server was stable, Kerberos and 389ds are still alive and all clients can still resolve all users. There is only one issue left (see bottom). First let us answer that: Am 23.07.15 um 18:28 schrieb Rich Megginson: # ldapsearch -xLLL -D cn=directory manager -W -s base -b dc=uni-wuppertal,dc=de This search should return immediately. If it hangs, then the problem is in slapd, and get a stack trace as before. [root@ipa httpd]# time ldapsearch -xLLL -D cn=directory manager -W -s base -b dc=pleiades,dc=uni-wuppertal,dc=de Enter LDAP Password: dn: dc=pleiades,dc=uni-wuppertal,dc=de objectClass: top objectClass: domain objectClass: pilotObject objectClass: domainRelatedObject objectClass: nisDomainObject dc: pleiades info: IPA V2.0 nisDomain: pleiades.uni-wuppertal.de associatedDomain: pleiades.uni-wuppertal.de real0m4.559s user0m0.403s sys 0m0.057s [root@ipa httpd]# Looks okay to us, or? 4 seconds? That seems way too long. What does the dirsrv access log look like for this sequence of operations? There will be a connection, a BIND, a SRCH, and an UNBIND. So.. here is the problem which is left over. When logging in as admin now through th web page or locally: [Thu Jul 23 21:43:47.340133 2015] [wsgi:error] [pid 1134] ipa: INFO: [jsonserver_session] wens...@pleiades.uni-wuppertal.de: radiusproxy_find(None, version=u'2.114'): SUCCESS [Thu Jul 23 21:43:48.758849 2015] [wsgi:error] [pid 1133] ipa: INFO: [jsonserver_session] wens...@pleiades.uni-wuppertal.de: user_find(None, version=u'2.114'): SUCCESS [Fri Jul 24 07:20:10.198903 2015] [wsgi:error] [pid 1134] ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while getting initial credentials [Fri Jul 24 07:20:10.198977 2015] [wsgi:error] [pid 1134] [Fri Jul 24 07:20:18.181715 2015] [wsgi:error] [pid 1133] ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while getting initial credentials [Fri Jul 24 07:20:18.181809 2015] [wsgi:error] [pid 1133] [Fri Jul 24 07:21:12.919751 2015] [wsgi:error] [pid 1134] ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while getting initial credentials [Fri Jul 24 07:21:12.919878 2015] [wsgi:error] [pid 1134] [root@ipa httpd]# kinit admin kinit: Clients credentials have been revoked while getting initial credentials [root@ipa httpd]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: ad...@pleiades.uni-wuppertal.de Valid starting Expires Service principal 07/23/2015 11:44:13 07/24/2015 11:44:08 HTTP/ipa.pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de 07/23/2015 11:44:11 07/24/2015 11:44:08 krbtgt/pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de [root@ipa httpd]# Hope you have an idea about that one as well :). I do not, sorry. Maybe one of our kerberos experts will know. Thanks Marisa and Torsten -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
