[Freeipa-users] Re: subCA OCSP on IPA Replica
Lucky I saw this early this morning as I'm about to destroy the machine. One other thing of note is that the ipa installation was done using ansible-freeipa. Hope it helps Dave [root@man-fb-ipa-02 ~]# uname -a Linux man-fb-ipa-02.testhost.com 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [root@man-fb-ipa-02 ~]# cat /etc/centos-release CentOS Linux release 7.6.1810 (Core) [root@man-fb-ipa-02 ~]# rpm -qa perl-Package-Constants-0.02-294.el7_6.noarch yum-3.4.3-161.el7.centos.noarch kbd-legacy-1.15.5-15.el7.noarch perl-IO-Compress-2.061-2.el7.noarch firewalld-0.5.3-5.el7.noarch bash-4.2.46-31.el7.x86_64 xorg-x11-font-utils-7.5-21.el7.x86_64 nss-softokn-freebl-3.36.0-5.el7_5.x86_64 net-tools-2.0-0.24.20131004git.el7.x86_64 python-sss-murmur-1.16.2-13.el7_6.8.x86_64 openssh-clients-7.4p1-16.el7.x86_64 copy-jdk-configs-3.3-10.el7_5.noarch audit-2.8.4-4.el7.x86_64 popt-1.13-16.el7.x86_64 mailcap-2.1.41-2.el7.noarch aic94xx-firmware-30-6.el7.noarch libattr-2.4.46-13.el7.x86_64 mod_nss-1.0.14-12.el7.x86_64 dracut-config-rescue-033-554.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 python-dateutil-1.5-7.el7.noarch keyutils-libs-1.5.8-3.el7.x86_64 python-ply-3.4-11.el7.noarch btrfs-progs-4.9.1-1.el7.x86_64 p11-kit-trust-0.23.5-3.el7.x86_64 cyrus-sasl-plain-2.1.26-23.el7.x86_64 rootfiles-8.1-11.el7.noarch libcgroup-0.41-20.el7.x86_64 iwl5000-firmware-8.83.5.1_1-69.el7.noarch policycoreutils-python-2.5-29.el7_6.1.x86_64 iwl7260-firmware-22.0.7.0-69.el7.noarch readline-6.2-10.el7.x86_64 libXau-1.0.8-2.1.el7.x86_64 iwl7265-firmware-22.0.7.0-69.el7.noarch which-2.20-7.el7.x86_64 libXrender-0.9.10-1.el7.x86_64 iwl6000-firmware-9.221.4.1-69.el7.noarch cpio-2.11-27.el7.x86_64 libXcomposite-0.4.4-4.1.el7.x86_64 grub2-common-2.02-0.76.el7.centos.1.noarch findutils-4.5.11-6.el7.x86_64 libXcursor-1.1.15-1.el7.x86_64 glibc-2.17-260.el7_6.6.x86_64 libxslt-1.1.28-5.el7.x86_64 libXxf86vm-1.1.4-1.el7.x86_64 libblkid-2.23.2-59.el7_6.1.x86_64 file-libs-5.11-35.el7.x86_64 libpath_utils-0.2.1-32.el7.x86_64 glib2-2.56.1-4.el7_6.x86_64 libaio-0.3.109-13.el7.x86_64 harfbuzz-1.7.5-2.el7.x86_64 nss-sysinit-3.36.0-7.1.el7_6.x86_64 cracklib-dicts-2.9.0-11.el7.x86_64 python-backports-1.0-8.el7.x86_64 dbus-libs-1.10.24-13.el7_6.x86_64 nss-softokn-3.36.0-5.el7_5.x86_64 python-jwcrypto-0.4.2-1.el7.noarch libssh2-1.4.3-12.el7_6.3.x86_64 libassuan-2.1.0-3.el7.x86_64 python-custodia-0.3.1-4.el7.noarch polkit-0.112-18.el7_6.1.x86_64 groff-base-1.22.2-8.el7.x86_64 python-netifaces-0.10.4-3.el7.x86_64 kernel-tools-libs-3.10.0-957.27.2.el7.x86_64 libunistring-0.9.3-9.el7.x86_64 lksctp-tools-1.0.17-2.el7.x86_64 util-linux-2.23.2-59.el7_6.1.x86_64 sysvinit-tools-2.88-14.dsf.el7.x86_64 libthai-0.1.14-9.el7.x86_64 device-mapper-event-libs-1.02.149-10.el7_6.8.x86_64 newt-0.52.15-4.el7.x86_64 sssd-common-pac-1.16.2-13.el7_6.8.x86_64 lvm2-libs-2.02.180-10.el7_6.8.x86_64 sssd-ldap-1.16.2-13.el7_6.8.x86_64 grub2-pc-2.02-0.76.el7.centos.1.x86_64 ethtool-4.8-9.el7.x86_64 libwayland-client-1.15.0-1.el7.x86_64 ipset-6.38-3.el7_6.x86_64 python-linux-procfs-0.4.9-4.el7.noarch pango-1.42.4-2.el7_6.x86_64 tuned-2.10.0-6.el7_6.4.noarch quota-4.01-17.el7.x86_64 systemd-sysv-219-62.el7_6.9.x86_64 libnetfilter_conntrack-1.0.6-1.el7_3.x86_64 gtk2-2.24.31-1.el7.x86_64 openssl-1.0.2k-16.el7_6.1.x86_64 gettext-0.19.8.1-2.el7.x86_64 xml-commons-apis-1.4.01-16.el7.noarch vim-minimal-7.4.160-6.el7_6.x86_64 xmlsec1-openssl-1.2.20-7.el7_4.x86_64 isorelax-0-0.15.release20050331.el7.noarch python-kitchen-1.1.1-5.el7.noarch pkgconfig-0.27.1-4.el7.x86_64 apache-commons-pool-1.6-9.el7.noarch libtevent-0.9.36-1.el7.x86_64 libdb-utils-5.3.21-24.el7.x86_64 hsqldb-1.8.1.3-14.el7.noarch libbasicobjects-0.1.1-32.el7.x86_64 mariadb-libs-5.5.60-1.el7_5.x86_64 resteasy-base-jaxrs-api-3.0.6-4.el7.noarch libsss_idmap-1.16.2-13.el7_6.8.x86_64 rpm-libs-4.11.3-35.el7.x86_64 objectweb-asm-3.3.1-9.el7.noarch libjpeg-turbo-1.2.90-6.el7.x86_64 python-pycurl-7.19.0-19.el7.x86_64 joda-time-2.2-3.tzdata2013c.el7.noarch fontpackages-filesystem-1.44-8.el7.noarch centos-logos-70.0.6-3.el7.centos.noarch avalon-logkit-2.1-14.el7.noarch xmlrpc-c-1.32.5-1905.svn2451.el7.x86_64 acl-2.2.51-14.el7.x86_64 jakarta-commons-httpclient-3.1-16.el7_0.noarch python-sssdconfig-1.16.2-13.el7_6.8.noarch pinentry-0.8.1-17.el7.x86_64 cal10n-0.7.7-4.el7.noarch libsss_nss_idmap-1.16.2-13.el7_6.8.x86_64 GeoIP-1.5.0-13.el7.x86_64 qdox-1.12.1-10.el7.noarch python-lxml-3.2.1-4.el7.x86_64 dmidecode-3.1-2.el7.x86_64 xpp3-1.1.3.8-11.el7.noarch certmonger-0.78.4-10.el7.x86_64 apache-commons-daemon-1.0.13-7.el7.x86_64 svrcore-4.1.3-2.el7.x86_64 hardlink-1.0-19.el7.x86_64 glassfish-jaxb-2.2.5-6.el7.noarch avahi-libs-0.6.31-19.el7.x86_64 libdaemon-0.14-7.el7.x86_64 resteasy-base-atom-provider-3.0.6-4.el7.noarch samba-common-libs-4.8.3-6.el7_6.x86_64 libpipeline-1.2.3-3.el7.x86_64 apache-commons-dbcp-1.4-17.el7.noarch libxshmfence-1.2-1.el7.x86_64 libmspack-0.5-0.6.alpha.el7.x86_64
[Freeipa-users] Re: subCA OCSP on IPA Replica
On Fri, Sep 06, 2019 at 11:27:52AM +1000, Fraser Tweedale via FreeIPA-users wrote: > On Thu, Sep 05, 2019 at 10:12:10AM -, David Etchen via FreeIPA-users > wrote: > > Ahh of course sudo I was trying su. > > > > I'm on Centos 7.6 running freeipa 4.6.4 all from the standard yum packages. > > > > It does look to be the exact same issue as you posted about Fedora 30. > > > Thanks. I will need to investigate this. Maybe it was triggered by > an update of some other package... > David could you please provide list of exact packages versions on the system (`rpm -qa`)? Thanks, Fraser ___ 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
[Freeipa-users] Re: subCA OCSP on IPA Replica
On Thu, Sep 05, 2019 at 10:12:10AM -, David Etchen via FreeIPA-users wrote:
> Ahh of course sudo I was trying su.
>
> I'm on Centos 7.6 running freeipa 4.6.4 all from the standard yum packages.
>
> It does look to be the exact same issue as you posted about Fedora 30.
>
Thanks. I will need to investigate this. Maybe it was triggered by
an update of some other package...
> This means that anyone running Centos 7.6 / RHEL 7.6 will be
> affected by this. (See below)
>
> As a work around if I manually imported the cert into nssdb
> /etc/pki/pki-tomcat/alias would dogtag kick into life or is there
> more than this required? I only ask out of interest as I'm going
> to rebuild this current setup on RHEL 8 which is running IPA 4.7.1
> which from what I can tell already includes the fix for this.
>
You need not only the certificate but also the signing key. Use
pk12util to export the cert and key from the one NSSDB, and import
into the other **with the same nickname**.
Cheers,
Fraser
> Thanks for your help on this.
> Dave
>
> The output from running comes out as
> [root@man-fb-ipa-02 ~]# sudo -u pkiuser /usr/libexec/ipa/ipa-pki-retrieve-key
> "caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93"
> man-fb-ipa-01.testhost.com
> Traceback (most recent call last):
> File "/usr/libexec/ipa/ipa-pki-retrieve-key", line 39, in
> main()
> File "/usr/libexec/ipa/ipa-pki-retrieve-key", line 30, in main
> keyfile=client_keyfile, keytab=client_keytab,
> File "/usr/lib/python2.7/site-packages/ipaserver/secrets/client.py", line
> 64, in __init__
> self.kemcli = KEMClient(self._server_keys(server, realm),
> File "/usr/lib/python2.7/site-packages/ipaserver/secrets/client.py", line
> 27, in _server_keys
> sk = JWK(**json_decode(self.ikk.find_key(principal, KEY_USAGE_SIG)))
> File "/usr/lib/python2.7/site-packages/ipaserver/secrets/kem.py", line 225,
> in find_key
> return conn.get_key(usage, kid)
> File "/usr/lib/python2.7/site-packages/ipaserver/secrets/kem.py", line 71,
> in get_key
> conn = self.connect()
> File "/usr/lib/python2.7/site-packages/ipaserver/secrets/common.py", line
> 40, in connect
> conn.sasl_interactive_bind_s('', auth_tokens)
> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
> sasl_interactive_bind_s
> return
> self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
> _ldap_call
> result = func(*args,**kwargs)
> LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified
> GSS failure. Minor code may provide more information (No Kerberos
> credentials available (default cache: KEYRING:persistent:17))', 'desc':
> 'Local error'}
>
> I also get the ca-show failure.
> [root@man-fb-ipa-02 ~]# ipa ca-show vpn
> ipa: ERROR: Request failed with status 500: Non-2xx response from CA REST
> API: 500.
___
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
[Freeipa-users] Re: subCA OCSP on IPA Replica
Ahh of course sudo I was trying su.
I'm on Centos 7.6 running freeipa 4.6.4 all from the standard yum packages.
It does look to be the exact same issue as you posted about Fedora 30.
This means that anyone running Centos 7.6 / RHEL 7.6 will be affected by this.
(See below)
As a work around if I manually imported the cert into nssdb
/etc/pki/pki-tomcat/alias would dogtag kick into life or is there more than
this required? I only ask out of interest as I'm going to rebuild this current
setup on RHEL 8 which is running IPA 4.7.1 which from what I can tell already
includes the fix for this.
Thanks for your help on this.
Dave
The output from running comes out as
[root@man-fb-ipa-02 ~]# sudo -u pkiuser /usr/libexec/ipa/ipa-pki-retrieve-key
"caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93"
man-fb-ipa-01.testhost.com
Traceback (most recent call last):
File "/usr/libexec/ipa/ipa-pki-retrieve-key", line 39, in
main()
File "/usr/libexec/ipa/ipa-pki-retrieve-key", line 30, in main
keyfile=client_keyfile, keytab=client_keytab,
File "/usr/lib/python2.7/site-packages/ipaserver/secrets/client.py", line 64,
in __init__
self.kemcli = KEMClient(self._server_keys(server, realm),
File "/usr/lib/python2.7/site-packages/ipaserver/secrets/client.py", line 27,
in _server_keys
sk = JWK(**json_decode(self.ikk.find_key(principal, KEY_USAGE_SIG)))
File "/usr/lib/python2.7/site-packages/ipaserver/secrets/kem.py", line 225,
in find_key
return conn.get_key(usage, kid)
File "/usr/lib/python2.7/site-packages/ipaserver/secrets/kem.py", line 71, in
get_key
conn = self.connect()
File "/usr/lib/python2.7/site-packages/ipaserver/secrets/common.py", line 40,
in connect
conn.sasl_interactive_bind_s('', auth_tokens)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
sasl_interactive_bind_s
return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
_ldap_call
result = func(*args,**kwargs)
LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information (No Kerberos credentials
available (default cache: KEYRING:persistent:17))', 'desc': 'Local error'}
I also get the ca-show failure.
[root@man-fb-ipa-02 ~]# ipa ca-show vpn
ipa: ERROR: Request failed with status 500: Non-2xx response from CA REST API:
500.
___
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
[Freeipa-users] Re: subCA OCSP on IPA Replica
On Wed, Sep 04, 2019 at 03:08:30PM -, David Etchen via FreeIPA-users wrote: > Hi Fraser, > > Thanks for replying. > > I've restarted both sides like you suggested but still don't see a > difference. I can see the back off time has started again like you said. > > [04/Sep/2019:15:20:12][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > Failed to retrieve key from any host. > [04/Sep/2019:15:20:12][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > KeyRetriever did not return a result. > [04/Sep/2019:15:20:12][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > Retrying in 15 seconds > [04/Sep/2019:15:20:27][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > Running ExternalProcessKeyRetriever > [04/Sep/2019:15:20:27][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > About to execute command: [/usr/libexec/ipa/ipa-pki-retrieve-key, > caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93, > man-fb-ipa-01.testhost.com] > [04/Sep/2019:15:20:28][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > Failed to retrieve key from any host. > [04/Sep/2019:15:20:28][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > KeyRetriever did not return a result. > [04/Sep/2019:15:20:28][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > Retrying in 22 seconds > > As I posted later running the command manually works and I get a reponse > containing what looks like a JSON response with certificate and wrapped_key > attributeswhich corespond to the subCA. I did have to do kinit first as I > wasn't logged in with an IPA user. > > I'm now puzzled as to why dogtag doesn't seem to get the response. Do you > know how I could emulate running the command as dogtag to see if it's > something to do with kerberos or something like that. > > I had a quick look in the audit log just to check it wasn't selinux related > but can't find anything. > > Just did some further testing, if I run the command manually I can see my > traffic in tcpdump connecting on port 443 to the master however when dogtag > is supposidly running the scripts I don't see any connection attempts. So it > looks like the script isn't actually running at least to the point where it > tries to talk to the master anyway. > > I dived off down the rabbit hole and thought maybe DNS isn't working for > dogtag so added an entry to /etc/hosts for the master IPA server but this > didn't make any difference. > > For good measure I've disabled selinux. I'm now looking to see if I can crank > up the logging output from dogtag to see if there is anything extra it's > saying. > > Any ideas welcome. > > Thanks > Dave > Try running: sudo -u pkiuser /usr/libexec/ipa/ipa-pki-retrieve-key \ "caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93" \ man-fb-ipa-01.testhost.com to run the command as pkiuser would run it. What OS and version are you running on? There was a recent bug on Fedora 30 with similar symptoms to what you are describing (see https://pagure.io/freeipa/issue/7964 for details). Cheers, Fraser ___ 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
[Freeipa-users] Re: subCA OCSP on IPA Replica
Hi Fraser, Thanks for replying. I've restarted both sides like you suggested but still don't see a difference. I can see the back off time has started again like you said. [04/Sep/2019:15:20:12][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Failed to retrieve key from any host. [04/Sep/2019:15:20:12][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: KeyRetriever did not return a result. [04/Sep/2019:15:20:12][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Retrying in 15 seconds [04/Sep/2019:15:20:27][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Running ExternalProcessKeyRetriever [04/Sep/2019:15:20:27][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: About to execute command: [/usr/libexec/ipa/ipa-pki-retrieve-key, caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93, man-fb-ipa-01.testhost.com] [04/Sep/2019:15:20:28][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Failed to retrieve key from any host. [04/Sep/2019:15:20:28][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: KeyRetriever did not return a result. [04/Sep/2019:15:20:28][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Retrying in 22 seconds As I posted later running the command manually works and I get a reponse containing what looks like a JSON response with certificate and wrapped_key attributeswhich corespond to the subCA. I did have to do kinit first as I wasn't logged in with an IPA user. I'm now puzzled as to why dogtag doesn't seem to get the response. Do you know how I could emulate running the command as dogtag to see if it's something to do with kerberos or something like that. I had a quick look in the audit log just to check it wasn't selinux related but can't find anything. Just did some further testing, if I run the command manually I can see my traffic in tcpdump connecting on port 443 to the master however when dogtag is supposidly running the scripts I don't see any connection attempts. So it looks like the script isn't actually running at least to the point where it tries to talk to the master anyway. I dived off down the rabbit hole and thought maybe DNS isn't working for dogtag so added an entry to /etc/hosts for the master IPA server but this didn't make any difference. For good measure I've disabled selinux. I'm now looking to see if I can crank up the logging output from dogtag to see if there is anything extra it's saying. Any ideas welcome. Thanks Dave ___ 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
[Freeipa-users] Re: subCA OCSP on IPA Replica
So just to add it seems that the 2nd IPA server hasn't managed to get the subCA cert & key as when I check the nssdb they aren't present on the 2nd IPA server. (See below) Running the command as my own user /usr/libexec/ipa/ipa-pki-retrieve-key "caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93" man-fb-ipa-01.testhost.com returns with what looks like a JSON response with certificate and wrapped_key attributes which corespond to the subCA. The question now is why does dogtag not get a response / thinks that it did not get a response? Master IPA Server certutil -L -d sql:/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 caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93 u,u,u caSigningCert cert-pki-caCTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u Replica IPA Server certutil -L -d sql:/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 caSigningCert cert-pki-caCTu,Cu,Cu auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u ___ 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
[Freeipa-users] Re: subCA OCSP on IPA Replica
On Wed, Sep 04, 2019 at 12:33:27PM -, David Etchen via FreeIPA-users wrote: > Hi Guys, > > I have a 2 host basic IPA setup both IPA servers are running dns & > ca. I'm running on Centos 7.6 using freeipa version 4.6.4 & > dogtag version 10.5.9 > > I've made a subCA called vpnca and a certificate policy and all > this is working fine with the exception of OCSP on the 2nd IPA > box. > > The original master works fine and issues OCSP responses for > certifcates issued by the vpnca (subCA) however the replica IPA > box fails to respond. > > I've had a look through the logs and found in the > /var/log/pki/pki-tomcat/ca/debug log an error on the 2nd box when > doing an OCSP request against it for a certificate issued by the > subCA. I should note here that OCSP requests for certificates > issued by the main IPA CA work fine it's only for ones issued by > the subCA on the replica that seem to be broken. > > I have also spotted the 2nd IPA server complaining that is can't > get caSigningCert > [04/Sep/2019:13:24:01][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > Running ExternalProcessKeyRetriever > [04/Sep/2019:13:24:01][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > About to execute command: [/usr/libexec/ipa/ipa-pki-retrieve-key, > caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93, > man-fb-ipa-01.testhost.com] > [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > Failed to retrieve key from any host. > [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > KeyRetriever did not return a result. > [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: > Retrying in 1946 seconds > > I'm presuming this is the reason OCSP is failing as it can't sign > the response for the subCA? > > Does anyone know if this is a known issue or if there is something > I need to modify to get the OCSP working on the replica host? > > Any help would be greatly appreciated > > Thanks > Dave > Hi Dave, Indeed OCSP is failing because the key is not presence (certificate issuance using the sub-CA will also fail on the replica). So we must investigate why key replication is failing. When a sub-CA is created, replicas contact the Custodia service on the master and request the key. First, restart the ipa-custodia service on the master (maybe it is not working properly and a restart will resolve it). You may wish to restart the pki-tomcatd@pki-tomcat service on the *replica* too, because sub-CA key replication attempts use exponential backoff (I see from the log it was up to 1946 seconds). If key replication is still failing have a look at the journal and the httpd logs on the *master* for clues. HTH, Fraser ___ 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
