As part of a larger IPA "health" checker and driven largely by necessity I have the beginning of a certificate checking tool available at https://github.com/rcritten/checkcerts
It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+ patches). YMMV.
There is not much of a user-friendly interface to it. There are only two options, debug and verbose, which increase the amount of debug output (and it is immense).
The UI is limited because I expect it to be rolled up into some larger tool at some point and don't want to have to throw away a ton of framework code.
It needs to be run on an IPA master and checks the things I thought of to check. I've only done limited testing on mostly brand new installs so I'd appreciate feedback. Don't freak out of it spits out errors as it could just be bugs on my part :-)
It is read-only so it shouldn't blow up anything.
So if you want to run it against your system and send me the any output I can try to figure out if it is my tool that is the issue or your system (it is supposed to help pro-actively diagnose issues after all).
To use just clone it from git (or download ipa-checkcerts.py from the repo)
Run it as root:
# kinit admin # python ipa-checkcerts.py IPA version 4.5.4-10.el7_5.3 Check CA status Check tracking Check NSS trust Check dates Checking certificates in CS.cfg Comparing certificates to requests in LDAP Checking RA certificate Checking authorities Checking host keytab Validating certificates Checking renewal master End-to-end cert API test Checking permissions and ownership All checks passed
thanks
rob
On Thu, 4 Oct 2018 at 23:22, Rob Crittenden via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
As part of a larger IPA "health" checker and driven largely by necessity I have the beginning of a certificate checking tool available at https://github.com/rcritten/checkcerts
It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+ patches). YMMV.
I ran this on CentOS 7.5 with IPA 4.5.0 and it worked for me - I've sent the output to Rob.
I got one error that I don't know how to fix -
Unknown certmonger ids: 20170919231606
What's the process for either removing or making it known?
Cheers L.
--- Kathi Weeks, *The Problem with Work: Feminism, Marxism, Antiwork Politics and Postwork Imaginaries* https://www.dukeupress.edu/The-Problem-with-Work/
Lachlan Musicman via FreeIPA-users wrote:
On Thu, 4 Oct 2018 at 23:22, Rob Crittenden via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
As part of a larger IPA "health" checker and driven largely by necessity I have the beginning of a certificate checking tool available at https://github.com/rcritten/checkcerts It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+ patches). YMMV.I ran this on CentOS 7.5 with IPA 4.5.0 and it worked for me - I've sent the output to Rob.
I got one error that I don't know how to fix -
Unknown certmonger ids: 20170919231606
What's the process for either removing or making it known?
I'll add something to the program about this too but for now you can run:
# getcert list -i 20170919231606
That will tell us what it is. It is perfectly fine to have certmonger track other certs on the system. I display unexpected once as a just-in-case.
It's supposed to display as just a warning. I'll fix that too since it is a little alarming.
rob
On Thu, 2018-10-04 at 09:21 -0400, Rob Crittenden via FreeIPA-users wrote:
As part of a larger IPA "health" checker and driven largely by necessity I have the beginning of a certificate checking tool available at https://github.com/rcritten/checkcerts
It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+ patches). YMMV.
There is not much of a user-friendly interface to it. There are only two options, debug and verbose, which increase the amount of debug output (and it is immense).
The UI is limited because I expect it to be rolled up into some larger tool at some point and don't want to have to throw away a ton of framework code.
It needs to be run on an IPA master and checks the things I thought of to check. I've only done limited testing on mostly brand new installs so I'd appreciate feedback. Don't freak out of it spits out errors as it could just be bugs on my part :-)
It is read-only so it shouldn't blow up anything.
So if you want to run it against your system and send me the any output I can try to figure out if it is my tool that is the issue or your system (it is supposed to help pro-actively diagnose issues after all).
To use just clone it from git (or download ipa-checkcerts.py from the repo)
Run it as root:
here is a tar file with the output with no options and with --verbose from my system. Please let me know when you need more information. The free-ipa was setup a number of years ago (on Centos 7.1?) and upgraded since with every new release. I already fixed some permission issues. The
Kind regards, Louis
P.s. /var/lib/ipa/ra-agent.pem contains the following: Certificate: Data: Version: 3 (0x2) Serial Number: 55 (0x37) Signature Algorithm: sha256WithRSAEncryption Issuer: O=HOME.FAZANT.NET, CN=Certificate Authority Validity Not Before: Apr 29 13:23:17 2018 GMT Not After : Apr 18 13:23:17 2020 GMT Subject: O=HOME.FAZANT.NET, CN=IPA RA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ea:41:9f:cc:2f:15:bc:b0:dc:ea:46:88:46:5d: 51:60:ca:66:ad:62:37:92:c9:85:9a:7d:8d:4a:c0: 8a:ef:c0:93:8b:3c:af:c1:e4:2e:b6:6d:be:ba:86: 33:95:bf:37:79:fb:a4:52:2c:99:6f:34:16:95:ed: 4e:c4:3c:9a:c0:c7:43:aa:17:9d:64:de:6f:12:9e: a7:5d:8f:80:d5:68:23:08:3d:03:b0:08:0d:29:6b: cf:b2:01:e9:39:82:54:63:c1:19:6c:6b:d6:df:9b: b7:dd:1e:cf:42:82:01:47:a4:07:57:e5:f7:b0:e3: a0:99:6e:52:d3:81:a8:dd:e1:94:1a:3a:d6:29:7a: 02:e4:31:94:37:44:b0:18:73:6d:de:b9:a8:a5:b3: 44:18:b9:66:7c:c0:53:bb:c0:5d:83:0f:31:c3:23: fb:44:57:23:6c:7e:c2:7b:15:3e:a3:11:b3:56:4e: 3e:f4:4f:0e:7b:49:f4:8c:42:b3:91:1b:2c:ea:b6: c7:fd:e7:9c:37:78:e3:a3:c7:2c:bf:e8:79:3b:85: f2:33:a0:a1:de:22:5c:59:e7:2b:44:3e:c4:8d:8b: a3:b8:b5:29:b9:17:6c:80:76:cc:25:d3:07:bd:6f: a3:7f:b5:83:bd:c5:49:a9:38:fd:9a:d1:04:20:b7: 63:6b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:5C:36:EB:08:E2:0C:1F:19:0A:B3:0F:80:21:DA:EF:22:F 7:A9:3C:3D
Authority Information Access: OCSP - URI:http://ipa-ca.home.fazant.net/ca/ocsp
X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Signature Algorithm: sha256WithRSAEncryption 5d:f1:ec:81:c7:a9:10:b2:d2:7b:22:51:bd:85:87:67:6b:8c: f9:14:2b:6b:38:47:0a:72:d6:8b:48:ab:18:42:c7:d3:bb:36: 27:e1:ab:7c:80:08:d0:40:ea:cf:96:23:87:bb:94:df:26:54: d0:8a:3e:fe:75:a3:c7:de:42:2e:ba:f4:b5:7e:74:7a:91:98: d6:2a:40:e0:0d:92:56:d6:04:f7:ee:78:19:70:df:81:32:fa: 9d:c7:e4:9d:48:3f:e7:c2:6f:4e:28:e7:c6:1c:ae:f9:58:17: 6e:f1:f1:14:7a:43:51:8c:45:f1:51:b9:90:92:3c:7e:12:9c: f4:e4:cb:14:e2:7e:c2:78:ea:68:97:20:96:dd:ea:d4:fb:59: 03:87:ef:70:9d:d6:40:d3:a1:a3:d8:21:0a:8c:d9:61:47:28: 88:d3:45:0b:3e:ad:cf:39:ac:0b:30:5b:41:5a:0e:cc:8f:69: ab:7d:74:ce:9b:15:82:4e:94:09:fe:6f:12:d9:2f:6e:c8:e0: 86:09:58:bf:ad:16:22:97:aa:4b:12:58:7f:b0:30:1f:ce:57: e7:ca:c5:ef:82:54:79:75:ba:cf:99:ba:e1:e4:a2:d8:b5:e3: 42:06:26:51:1a:95:68:60:ba:1c:eb:80:1f:f6:a2:45:b5:5a: 69:d7:34:03
Louis Lagendijk via FreeIPA-users wrote:
On Thu, 2018-10-04 at 09:21 -0400, Rob Crittenden via FreeIPA-users wrote:
As part of a larger IPA "health" checker and driven largely by necessity I have the beginning of a certificate checking tool available at https://github.com/rcritten/checkcerts
It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+ patches). YMMV.
There is not much of a user-friendly interface to it. There are only two options, debug and verbose, which increase the amount of debug output (and it is immense).
The UI is limited because I expect it to be rolled up into some larger tool at some point and don't want to have to throw away a ton of framework code.
It needs to be run on an IPA master and checks the things I thought of to check. I've only done limited testing on mostly brand new installs so I'd appreciate feedback. Don't freak out of it spits out errors as it could just be bugs on my part :-)
It is read-only so it shouldn't blow up anything.
So if you want to run it against your system and send me the any output I can try to figure out if it is my tool that is the issue or your system (it is supposed to help pro-actively diagnose issues after all).
To use just clone it from git (or download ipa-checkcerts.py from the repo)
Run it as root:
here is a tar file with the output with no options and with --verbose from my system. Please let me know when you need more information. The free-ipa was setup a number of years ago (on Centos 7.1?) and upgraded since with every new release. I already fixed some permission issues. The
Kind regards, Louis
Thanks! I'll take a look at this and get back to you next week, perhaps privately, we'll see (mostly based on whether I think it is of general interest to work through the issues).
rob
Let's tackle these one at a time.
Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name': 'IPA', 'cert-database': '/etc/httpd/alias', 'cert-postsave-command': '/usr/libexec/ipa/certmonger/restart_httpd'}
Did you provide your own certificate for the web server (e.g. like from Let's Encrypt?) What is the value of NSSNickname in /etc/httpd/conf.d/nss.conf?
Let me get back to you on the template subjects not matching. I want to run this past the dogtag team to see if my test is correct or not. It could be a red herring.
For all of the "Error looking up CA entry in IPA <UUID>: no matching entry found"
This means that a subCA is defined in dogtag that is not defined in IPA. This may not be a problem but it is definitely strange. What this test does is compare the contents of ou=authorities,ou=ca,o=ipaca to those in cn=cas,cn=ca,dc=example,dc=com. I'll run this one past the CS team too.
In the meantime can you provide some of the contents of those entries that are in dogtag?
$ ldapsearch -x -D 'cn=directory manager' -W -b ou=authorities,ou=ca,o=ipaca > /tmp/cas.ldif
Validation of /var/lib/ipa/ra-agent.pem failed: Command '/usr/bin/openssl verify /var/lib/ipa/ra-agent.pem' returned non-zero exit status 2
According to the verify(1) man page 2 == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT which suggests that the IPA CA is not in the global cert bundle.
This should fix it:
# ipa-certupdate
Thanks for helping out!
rob
Gah, regarding
Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name': 'IPA', 'cert-database': '/etc/httpd/alias', 'cert-postsave-command': '/usr/libexec/ipa/certmonger/restart_httpd'}
never mind. The cert is in the verbose output you sent! It is fine and issued by IPA.
So this looks like the tracking is simply missing. Can you run:
# ipa-getcert list
You should have two certs, one for Apache tracking /etc/httpd/alias and one for LDAP tracking /etc/dirsrv/slapd-REALM
If you have one for Apache can you provide the output of the list command?
If you don't then you can re-create it (this doesn't touch the certs themselves) via:
# ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -C /usr/libexec/ipa/certmonger/restart_httpd
rob
Gah, regarding
Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name': 'IPA', 'cert-database': '/etc/httpd/alias', 'cert-postsave-command': '/usr/libexec/ipa/certmonger/restart_httpd'}
never mind. The cert is in the verbose output you sent! It is fine and issued by IPA.
So this looks like the tracking is simply missing. Can you run:
# ipa-getcert list
You should have two certs, one for Apache tracking /etc/httpd/alias and one for LDAP tracking /etc/dirsrv/slapd-REALM
If you have one for Apache can you provide the output of the list command?
If you don't then you can re-create it (this doesn't touch the certs themselves) via:
# ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -C /usr/libexec/ipa/certmonger/restart_httpd
rob
On Mon, 2018-10-22 at 12:07 -0400, Rob Crittenden via FreeIPA-users wrote:
Gah, regarding
Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name': 'IPA', 'cert-database': '/etc/httpd/alias', 'cert-postsave-command': '/usr/libexec/ipa/certmonger/restart_httpd'}
never mind. The cert is in the verbose output you sent! It is fine and issued by IPA.
So this looks like the tracking is simply missing. Can you run:
# ipa-getcert list
You should have two certs, one for Apache tracking /etc/httpd/alias and one for LDAP tracking /etc/dirsrv/slapd-REALM
If you have one for Apache can you provide the output of the list command?
If you don't then you can re-create it (this doesn't touch the certs themselves) via:
# ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -C /usr/libexec/ipa/certmonger/restart_httpd
Thanks for looking into my output! Much appreciated
/etc/httpd/alias is being tracked. Here is the output: [root@ipa1 checkcerts]# ipa-getcert list Number of certificates and requests being tracked: 9. Request ID '20181001153507': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-HOME- FAZANT-NET',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-HOME-FAZANT-NET/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-HOME- FAZANT-NET',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=HOME.FAZANT.NET subject: CN=ipa1.home.fazant.net,O=HOME.FAZANT.NET expires: 2020-10-03 21:06:09 UTC principal name: ldap/ipa1.home.fazant.net@HOME.FAZANT.NET 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 HOME-FAZANT-NET track: yes auto-renew: yes Request ID '20181003195731': 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=HOME.FAZANT.NET subject: CN=ipa1.home.fazant.net,O=HOME.FAZANT.NET expires: 2020-05-21 13:53:40 UTC principal name: HTTP/ipa1.home.fazant.net@HOME.FAZANT.NET key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes
BR, Louis
Hi Rob, Here are the answer to your questions.
On Mon, 2018-10-22 at 12:01 -0400, Rob Crittenden via FreeIPA-users wrote:
Let's tackle these one at a time.
Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name': 'IPA', 'cert-database': '/etc/httpd/alias', 'cert-postsave-command': '/usr/libexec/ipa/certmonger/restart_httpd'}
Did you provide your own certificate for the web server (e.g. like from Let's Encrypt?) What is the value of NSSNickname in /etc/httpd/conf.d/nss.conf?
No, the IPA servers are not publicly reachable, all hosts within my network use ipa certificates only. Only 2 nodes (https and mail) with public IP-addresses use let's encrypt
/etc/httpd/conf.d/nss.conf has: # SSL Certificate Nickname: # The nickname of the RSA server certificate you are going to use. NSSNickname Server-Cert # SSL Certificate Nickname: # The nickname of the ECC server certificate you are going to use, if you # have an ECC-enabled version of NSS and mod_nss #NSSECCNickname Server-Cert-ecc
Let me get back to you on the template subjects not matching. I want to run this past the dogtag team to see if my test is correct or not. It could be a red herring.
For all of the "Error looking up CA entry in IPA <UUID>: no matching entry found"
This means that a subCA is defined in dogtag that is not defined in IPA. This may not be a problem but it is definitely strange. What this test does is compare the contents of ou=authorities,ou=ca,o=ipaca to those in cn=cas,cn=ca,dc=example,dc=com. I'll run this one past the CS team too.
In the meantime can you provide some of the contents of those entries that are in dogtag?
$ ldapsearch -x -D 'cn=directory manager' -W -b ou=authorities,ou=ca,o=ipaca > /tmp/cas.ldif
Attached the file as requested
Validation of /var/lib/ipa/ra-agent.pem failed: Command '/usr/bin/openssl verify /var/lib/ipa/ra-agent.pem' returned non-zero exit status 2
According to the verify(1) man page 2 == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT which suggests that the IPA CA is not in the global cert bundle.
This should fix it:
# ipa-certupdate
That indeed fixed the issue, thanks
Thanks for helping out!
Well thank you guy for the great product and your efforts to improve it!
rob _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Louis Lagendijk via FreeIPA-users wrote:
On Mon, 2018-10-22 at 12:07 -0400, Rob Crittenden via FreeIPA-users wrote:
Gah, regarding
Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name': 'IPA', 'cert-database': '/etc/httpd/alias', 'cert-postsave-command': '/usr/libexec/ipa/certmonger/restart_httpd'}
never mind. The cert is in the verbose output you sent! It is fine and issued by IPA.
So this looks like the tracking is simply missing. Can you run:
# ipa-getcert list
You should have two certs, one for Apache tracking /etc/httpd/alias and one for LDAP tracking /etc/dirsrv/slapd-REALM
If you have one for Apache can you provide the output of the list command?
If you don't then you can re-create it (this doesn't touch the certs themselves) via:
# ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -C /usr/libexec/ipa/certmonger/restart_httpd
Thanks for looking into my output! Much appreciated
/etc/httpd/alias is being tracked. Here is the output: [root@ipa1 checkcerts]# ipa-getcert list Number of certificates and requests being tracked: 9. Request ID '20181001153507': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-HOME- FAZANT-NET',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-HOME-FAZANT-NET/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-HOME- FAZANT-NET',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=HOME.FAZANT.NET subject: CN=ipa1.home.fazant.net,O=HOME.FAZANT.NET expires: 2020-10-03 21:06:09 UTC principal name: ldap/ipa1.home.fazant.net@HOME.FAZANT.NET 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 HOME-FAZANT-NET track: yes auto-renew: yes Request ID '20181003195731': 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=HOME.FAZANT.NET subject: CN=ipa1.home.fazant.net,O=HOME.FAZANT.NET expires: 2020-05-21 13:53:40 UTC principal name: HTTP/ipa1.home.fazant.net@HOME.FAZANT.NET key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes
It is missing the post-save command. To fix it run:
# ipa-getcert -i 20181003195731 -C /usr/libexec/ipa/certmonger/restart_httpd
The consequence of not having the post-save command is that after the cert is renewed Apache wouldn't be restarted to utilize it potentially giving you a bit of downtime.
rob
Rob, I'd love to test your tool, as part of working on my problem "ipa.service fails to start", but I still run 4.4.0-12.0.1.el7.x86_64, hence do you think this is the obstacle?
Again, as part of "ipa.service fails to start" work, I was hoping to add new IPA server 4.5.4, but ipa-replica-prepare (from v4.4.0) fails with:
Creating SSL certificate for the Directory Server cannot connect to 'https://ca-ldap02.domain.com:8443/ca/ee/ca/profileSubmitSSLClient': (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.
One more thing, mine domain level is 0, will it help raising to 1 and is this process harmful? I am desperate to try things that can possibly lead to resolving my expire cert problems.
thanks, Zarko
Z D via FreeIPA-users wrote:
Rob, I'd love to test your tool, as part of working on my problem "ipa.service fails to start", but I still run 4.4.0-12.0.1.el7.x86_64, hence do you think this is the obstacle?
I haven't tried it. It won't hurt anything to try though.
Again, as part of "ipa.service fails to start" work, I was hoping to add new IPA server 4.5.4, but ipa-replica-prepare (from v4.4.0) fails with:
Creating SSL certificate for the Directory Server cannot connect to 'https://ca-ldap02.domain.com:8443/ca/ee/ca/profileSubmitSSLClient': (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.
Without a CA you can't create a replica.
One more thing, mine domain level is 0, will it help raising to 1 and is this process harmful? I am desperate to try things that can possibly lead to resolving my expire cert problems.
Trying to upgrade would not help and could make things worse.
Check out this thread for configuring dogtag to use basic LDAP auth instead of cert auth, it might help unstick things:
https://www.redhat.com/archives/freeipa-users/2017-January/msg00216.html
rob
Hi Rob, it won't work on 4.4.0 for now.
# python2 /tmp/checkcerts/ipa-checkcerts.py Traceback (most recent call last): File "/tmp/checkcerts/ipa-checkcerts.py", line 21, in <module> from ipalib.install import certstore ImportError: No module named install
I guess it's not appropriate to use this thread for my issue, but as soon I go back in time, dogtag-ipa-ca-renew-agent-submit, ipa-dnskeysyncd and named-pkcs11 all read messages about "LDAP error: Invalid credentials: bind to LDAP server failed"
Zarko D via FreeIPA-users wrote:
Hi Rob, it won't work on 4.4.0 for now.
# python2 /tmp/checkcerts/ipa-checkcerts.py Traceback (most recent call last): File "/tmp/checkcerts/ipa-checkcerts.py", line 21, in <module> from ipalib.install import certstore ImportError: No module named install
Right and porting to 4.4.x is possible but not super-trivial and not currently on my radar. There are several non-trivial pieces missing.
I guess it's not appropriate to use this thread for my issue, but as soon I go back in time, dogtag-ipa-ca-renew-agent-submit, ipa-dnskeysyncd and named-pkcs11 all read messages about "LDAP error: Invalid credentials: bind to LDAP server failed"
Yeah better to keep it in the other thread.
rob
freeipa-users@lists.fedorahosted.org
-
Lachlan Musicman -
Louis Lagendijk -
Rob Crittenden -
Z D -
Zarko D