/var/log/pki/pki-tomcat/ca/debug didn't hold anything that looked informative to me, but I'm working to get it somewhere you might take a look and see if you spot something I don't.

After adding the server.conf as suggested, I noted this in /var/log/messages on our IPA server "zsipa2". I'm not sure it's helpful, but here it is:


2017-05-31T14:54:10.222286+00:00 zsipa2 ns-slapd: [31/May/2017:14:54:10.222079990 +0000] slapi_ldap_bind - Error: coudl not bind id [cn=Replication Manager masterAgreement1-zsipa2.damascusgrp.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success)

Is there a way to replace our certs and get moving again? My queue of signing requests is building up. I'm not opposed to "nuclear" options.


Bret


On 05/30/2017 11:31 AM, Rob Crittenden wrote:
Bret Wortman via FreeIPA-users wrote:
Still trying to get my CA working.

In the IPA web UI, under Authentication -> Certificates, I can see a
number of certs listed as VALID, EXPIRED, or REVOKED_EXPIRED. But I can
also see many more that are greyed out, and whose "Issuing CA" and
"Status" columns are empty. Does this begin to point toward a solvable
problem?
I think these are probably red herrings.

As I mentioned cert-find uses a different API than the rest of the CA
commands. It is interesting that the CA is at least partially up I guess.

The authenticated requests IPA is making to dogtag are returning 503
Service Unavailable which suggests that the CA isn't fully running, or
there is some issue with the AJP connector. I'm frankly surprised that
the REST API works at all as I though the CA was an all-or-nothing affair.

/var/log/pki/pki-tomcat/ca/debug may hold clues on what is going on.

You might also try creating /etc/ipa/server.conf containing:

[global]
debug=True

This will increase the server-level debugging but I doubt you'll get
much useful out of it in this case given it is the CA that is the
problem, but who knows.

rob


On 05/18/2017 08:58 AM, Bret Wortman wrote:
Oops, the slapd messages are arriving every 60s, not 5m.


On 05/18/2017 08:56 AM, Bret Wortman wrote:
httpd_error seems to give the most information. When i try to use ipa
cert-show:

ipa: INFO: [jsonserver_kerb] ad...@damascusgrp.com: ping(): SUCCESS
(111)Connection refused: AH00957: AJP: attempt to connect to
127.0.0.1:8009 (localhost) failed
AH00959: ap_proxy_connect_backend disabling worker for (locahost) for 60s
[client 192.168.208.54:52714] AH00896: failed to make connection to
backend: localhost
ipa: ERROR: ra.get_certificate(): Unable to communicate with CMS (503)
ipa: INFO: [jsonserver_kerb] ad...@damascusgrp.com:
cert_show/1(u'895', version=u'2.213'): CertificateOperationError

/var/log/pki/pki-tomcat/ca/debug just loops through the same set of
messages every 5 minutes or so but doesn't seem to error.

/var/log/pki/localhost_access_log.2017-05-18.txt is basically empty
except for a single entry (for a POST to /ca/admin/ca/getStatus)

Nothing shows up in dirsrv/slapd-DAMASCUSGRP-COM/errors or access
when I issue the request, but periodic messages do appear about every
5 minutes or so.


On 05/18/2017 08:43 AM, Bret Wortman wrote:
On 04/26/2017 06:02 PM, Rob Crittenden wrote:
Bret Wortman wrote:
So I can see my certs using cert-find, but can't get details using
cert-show or add new ones using cert-request.

      # ipa cert-find
      :
      ------------------------------
      Number of entries returned 385
      ------------------------------
      # ipa cert-show 895
      ipa: ERROR: Certificate operation cannot be completed: Unable to
      communicate with CMS (503)
      # ipa cert-show 1 (which does not exist)
      ipa: ERROR: Certificate operation cannot be completed: Unable to
      communicate with CMS (503)
      # ipa cert-status 895
      ipa: ERROR: Certificate operation cannot be completed: Unable to
      communicate with CMS (503)
      #

Is this an IPV6 thing? Because ipactl shows everything green and
certmonger is running.
Doubtful.

cert-find and cert-show use different APIs in dogtag. cert-find
uses the
newer RESTful API and cert-show uses the older XML-based API (and is
authenticated). I'm guessing that is where the issue lies.

What I'd recommend doing is noting the time, restarting the CA, and
then
plow through the debug log looking for failures. It could be that
the CA
is only partially up (and I'd check your CA subsystem certs as well).
Which debug log, specifically, do you think will help? I'm also not
sure what you mean by, "check your CA subsystem certs." We still
have pending CSRs that we can't grant until I get this working again.
rob

Bret


On 04/26/2017 09:03 AM, Bret Wortman wrote:
Digging still deeper:

      # ipa cert-request f.f
--principal=HTTP/`hostname`@DAMASCUSGRP.COM
      ipa: ERROR: Certificate operation cannot be completed:
Unable to
      communicate with CMS (503)

Looks like this is an HTTP error; so is it possible that my IPA
thinks
it has a CA but there's no CMS available?


On 04/26/2017 08:41 AM, Bret Wortman wrote:
Using the firefox debugger, I get these errors when trying to
pop up
the New Certificate dialog:

      Empty string passed to getElementById().             (5)
      jquery.js:4:1060
      TypeError: u is undefined
      app.js:1:362059
      Empty string passed to getElementById().             (5)
      jquery.js:4:1060
      TypeError: t is undefined
      app.js:1:217432

I'm definitely not a web kind of guy so I'm not sure if this is
helpful or not. This is on 4.4.0, API Version 2.213.


Bret


On 04/26/2017 08:35 AM, Bret Wortman wrote:
Good news. One of my servers _does_ have CA installed. So why does
"Action -> New Certificate" not do anything on this or any
other server?


Bret


On 04/25/2017 02:52 PM, Bret Wortman wrote:
I recently had to upgrade all my Fedora IPA servers to C7. It
went
well, and we've been up and running nicely on 4.4.0 on C7 for the
past month or so.

Today, someone came and asked me to generate a new certificate
for
their web server. All was good until I went to the IPA UI and
tried
to perform Actions->New Certificate, which did nothing. I tried
each of our 3 servers in turn. All came back with no popup window
and no error, either.

I suspect the problem might be that we no longer have a CA server
due to the method I used to upgrade the servers. I likely
missed a
"--setup-ca" in there somewhere, so my rolling update rolled over
the CA.

What's my best hope of recovery? I never ran this before, so I'm
not sure if this shows that I'm missing a CA or not:

      # ipa ca-find
      ------------
      1 CA matched
      ------------
        Name: ipa
        Description IPA CA
        Authority ID: 3ce3346[...]
        Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM
        Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM
      ----------------------------
      Number of entries returned 1
      ----------------------------
      # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA,
      O=DAMASCUSGRP.COM"
      ipa: ERROR: Failed to authenticate to CA REST API
      # klist
      Ticket cache: KEYRING:persistent:0:0
      Default principal: ad...@damascusgrp.com

      Valid starting      Expires              Service principal
      04/25/2017 18:48:26 04/26/2017 18:48:21
      krbtgt/damascusgrp....@damascusgrp.com
      #


What's my best path of recovery?

--
*Bret Wortman*
The Damascus Group









_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to