Re: [Pki-users] expired pki-server 10.3.3 certificates
by Z D
Hi John, thanks for the feedback.
I used this URL as help to disable self tests.
https://www.dogtagpki.org/wiki/Offline_System_Certificate_Renewal#Manual_...
Many of "pki-server" command options are not present for me, since pki-server version is 10.3, I believe the doc applies for 10.5.
But I was able to disable self test and PKI is responsive now.
After system time is back, I use 'getcert resubmit' to renew a cert and seeing this certmonger errors
Basically is some :
"ACIError: Insufficient access: Invalid credentials"
[journalctl messages]
------------------------------
Aug 10 01:04:34 ca-ldap01 dogtag-ipa-ca-renew-agent-submit: Traceback (most recent call last):#012 File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 511, in <module>#012 sys.exit(main())#012 File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 497, in main#012 if ca.is_renewal_master():#012 File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1188, in is_renewal_master#012 self.ldap_connect()#012 File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 177, in ldap_connect#012 conn.do_bind(self.dm_password, autobind=self.autobind)#012 File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1690, in do_bind#012 self.do_sasl_gssapi_bind(timeout=timeout)#012 File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1668, in do_sasl_gssapi_bind#012 self.__bind_with_wait(self.gssapi_bind, timeout)#012 File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1650, in __bind_with_wait#012 bind_func(*args, **kwargs)#012 File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1108, in gssapi_bind#012 '', auth_tokens, server_controls, client_controls)#012 File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__#012 self.gen.throw(type, value, traceback)#012 File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 973, in error_handler#012 raise errors.ACIError(info="%s %s" % (info, desc))#012ACIError: Insufficient access: Invalid credentials
[syslog messages]
------------------------
Aug 10 01:04:34 ca-ldap01 dogtag-ipa-ca-renew-agent-submit[9333]: Traceback (most recent call last):
File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 511, in <module>
sys.exit(main())
File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 497, in main if ca.is_renewal_master():
File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1188, in is_renewal_master
self.ldap_connect()
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 177, in ldap_connect
conn.do_bind(self.dm_password, autobind=self.autobind)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1690, in do_bind
self.do_sasl_gssapi_bind(timeout=timeout)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1668, in do_sasl_gssapi_bind
self.__bind_with_wait(self.gssapi_bind, timeout)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1650, in __bind_with_wait
bind_func(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1108, in gssapi_bind
'', auth_tokens, server_controls, client_controls)
File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
self.gen.throw(type, value, traceback)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 973, in error_handler
raise errors.ACIError(info="%s %s" % (info, desc))
ACIError: Insufficient access: Invalid credentials
Aug 10 01:04:34 ca-ldap01 certmonger[8834]: 2018-08-10 01:04:34 [8834] Internal error
Is there any URL that's relevant for pki 10.3
thanks in advance, Zarko
________________________________
From: John Magne <jmagne(a)redhat.com>
Sent: Wednesday, November 14, 2018 6:16 PM
To: Z D
Subject: Re: [Pki-users] expired pki-server 10.3.3 certificates
Hi:
YOu can try to temporarily disable the self tests for you ca, until
the new certs are resolved.
Look in the CS.cfg file for the ca in question and there is a big section
controlling the self tests. Just experiment with commenting out the tests and see if that
gets you past the hurdle..
<https://www.redhat.com/mailman/listinfo/pki-users>
5 years, 4 months
Re: [Pki-users] [Freeipa-users] OCSP responses for an external CA
by Fraser Tweedale
Hi Andrew,
Responses inline.
On Wed, Nov 28, 2018 at 05:35:11PM -0800, Andrew C Dingman via FreeIPA-users wrote:
> Hi, all
>
> I'm not sure the following is feasible, but IHAC who may want to use
> IPA in an air-gapped network while relying on smart card authentication
> using certificates from a very large, external CA. Can anyone give me
> an idea of whether the following scenario is feasible, and if so,
> supportable?
>
> External certificate authority E issues user certificates and
> provisions smart card tokens. (It runs RHCS, if that matters.) Inside
> the isolated network, users are separately maintained in IPA domain P.
> When each user is created in P, a certificate issued by E is added to
> the user's entry. That certificate is used for pkinit and ssl/tls
> client authentication to services in P.
>
> So far, my understanding is that this should be feasible provided that
> E is added as a trusted authority in various places, but I'm a little
> fuzzy on the pkinit piece. Where it gets really problematic is dealing
> with CRLs.
>
Yes, so far so good. That's all supported.
> Because P and its relying parties are isolated, they can't use OCSP to
> check current validity of a certificate. To avoid the hassles of
> distributing CRLs to all relying systems and services manually, would
> it be possible to add those CRLs to the set served by the OCSP
> responder in P? Obviously the responses would be signed by P rather
> than E, but if P has verified the CRL on which they were based it seems
> at least potentially viable.
>
X.509 supports delegating OCSP signing authority to 3rd parties.
But we do not support it in Dogtag or FreeIPA at this time. It
would be complex to implement.
If they are already using RHCS, they could consider using a
standalone OCSP subsystem to service the OCSP requests. I'm not
sure about the setup detail, i.e. whether regulary transporting
CRL(s) from the air-gapped CA to the OCSP subsystem is sufficient,
or whether LDAP replication must be used. I've Cc'd pki-users ML
for input from people who hopefully know more about the OCSP
subsystem than I do.
On the user certificate issuance side, they are using RHCS. So it
is straightforward to configure a profile that sets the Authority
Information Access extension to point to whatever OCSP responder
they end up using.
>
> As currently envisioned, E would be completely unaware of the existence
> of P,
>
Not possible. E must at least be aware of P to the extent that it
has issued an delegated OCSP signing certificate to P. Otherwise
the OCSP responses issued by P, pertaining to certificates issued by
E, cannot be trusted by clients, even if they trust P as a CA.
> but P would trust certificates issued by E. If that isn't
> feasible, would it make any difference if P's CA were subordinate to E?
>
There are some scenarios that conceptually work (e.g. P's CA
certificate, issued by E, contains the id-kp-OCSPSigning Extended
Key Usage OID). But it is irrelevant because I do not believe there
is a way to configure a Dogtag CA subsystem to service OCSP requests
on behalf of an external CA.
> Thanks in advance for any guidance you can offer.
>
You're welcome.
Cheers,
Fraser
5 years, 5 months
Need help in setting up CRL distribution point
by Akshath Hegde
Hi. I have installed the dogtag pki on centos 7. My client is a router
which uses scep for enrollment. I'm able to authenticate and enroll. But
I'm having trouble in setting up the CRL distribution point. The client
seems to be sending the scep request with a specific URL everytime. So I
need to modify the location where the CRL is placed and the URL to which
the scep server responds and publish this with the certificate. Right now I
can see this is the request -
ca/ee/ca/getCRL?operation=getCRL&crlIssuingPoint=MasterCRL. I modified the
caRouterCert.cfg profile to change the URL that gets published. But Im not
able to figure out how to change the location and map the URI to that. Any
help would be appreciated
Thanks
5 years, 5 months
expired pki-server 10.3.3 certificates
by Z D
Hi there,
I've been using IPA 4.4.0 and pki-server 10.3.3 and have posting on freeipa mailing list, but unfortunately haven't resolved the problem so I am looking for support on this mailing list.
[1] since certmonger failed to renew certs, I believe resolution is going back in time when all certs are valid and restart certmonger service
[2] I went back into time, and verified that pki-server is running, with command:
SSL_DIR=/etc/httpd/alias/ curl -v -o /dev/null --cacert /etc/ipa/ca.crt https://`hostname`:8443/ca/agent/ca/profileReview
[3] restart certmonger and getcert list shoes four certs in submitting status
# getcert list | egrep "certificate|expire|status"
status: SUBMITTING
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2018-08-14 20:49:38 UTC
status: SUBMITTING
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2018-08-14 20:49:35 UTC
status: SUBMITTING
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB'
expires: 2018-08-14 20:49:36 UTC
status: MONITORING
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2036-08-24 20:49:35 UTC
status: SUBMITTING
certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' expires: 2018-08-14 20:50:00 UTC
status: MONITORING
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB'
expires: 2020-07-07 01:47:45 UTC
[4] Here is where problem starts, the CA stop running, and /var/lib/pki/pki-tomcat/logs/ca/selftests.log report
0.localhost-startStop-1 - [10/Aug/2018:02:28:05 PDT] [20] [1] CAPresence: CA is present 0.localhost-startStop-1 - [10/Aug/2018:02:28:05 PDT] [20] [1] SystemCertsVerification: system certs verification failure: Certificate auditSigningCert cert-pki-ca is invalid: Invalid certificate: (-8181) Peer's Certificate has expired. 0.localhost-startStop-1 - [10/Aug/2018:02:28:05 PDT] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED!
[5] I see that 'auditSigningCert' and ocspSigningCert have been renewed, so obviously at this very moment their validity time is not same as for other certs. Hence selftests.logs reports auditSigningCert is invalid, and CA stops running and I am left with tow certs not renewed. New cert list now is:
# getcert list | egrep "certificate|expires"
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2020-10-29 06:35:38 UTC
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2020-10-11 20:15:53 UTC
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB'
expires: 2018-08-14 20:49:36 UTC
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB'
expires: 2036-08-24 20:49:35 UTC
certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' expires: 2018-08-14 20:50:00 UTC
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB'
expires: 2020-07-07 01:47:45 UTC
The question now is how to work around this problem? Instead of restarting certmonger service, is there way to manually renew cert.
thanks, Zarko
5 years, 5 months
