Hi !

I am running into a weird problem with my IPA Server, and the
certificates management. My setup is :
CentOS 6.6
pki-ca-9.0.3-38.el6_6.noarch
ipa-server-3.0.0-42.el6.centos.x86_64
Linux ipa_server 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

The server has been installed two years ago, and all the certificates on
the master server expired this month. (2 year validity). Apparently,
they were not properly tracked by certmonger, so they were not renewed.

By doing some getcert stop-tracking, then getcert start-tracking xxxx, I
was able to track 8 of the 9 certificates that I can display with
getcert list on this server.

There is one that remains expired, despite all the efforts I put into
renewing it. This is the one used for the pki-ca administration pages
reachable on ports 9443, 9444 and 9445. Here is its status after trying
to resubmit it :
getcert resubmit -i 20150511145941 -K HTTP/ipa_server
getcert list -i 20150511145941

Number of certificates and requests being tracked: 9.
Request ID '20150511145941':
        status: CA_UNREACHABLE
        ca-error: Server at https://ipa_server/ipa/xml failed request,
will retry: 4301 (RPC failed at server.  Certificate operation cannot be
completed: FAILURE (Invalid Request)).
        stuck: no
        key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin='1234'
        certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
        CA: IPA
        issuer: CN=Certificate Authority,O=ipa_domain
        subject: CN=ipa_server,O=ipa_domain
        expires: 2015-04-09 04:58:33 UTC
        key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth
        pre-save command:
        post-save command:
        track: yes
        auto-renew: yes


I tried to stop tracking it, and then tracking it again, with no luck :
getcert start-tracking -d "/var/lib/pki-ca/alias" -n "subsystemCert
cert-pki-ca" -t "NSS Certificate DB" -P 1234 -r -c IPA

I changed the trust settings as well, still not working :
sh-4.1# certutil -M -n "Server-Cert cert-pki-ca" -d
/var/lib/pki-ca/alias -t u,u,Pu

sh-4.1# certutil -L -d /var/lib/pki-ca/alias
Certificate Nickname                                         Trust
Attributes
SSL,S/MIME,JAR/XPI
ocspSigningCert cert-pki-ca                                  u,u,u
subsystemCert cert-pki-ca                                    u,u,u
auditSigningCert cert-pki-ca                                 u,u,Pu
caSigningCert cert-pki-ca                                    CTu,Cu,Cu
Server-Cert cert-pki-ca                                      u,u,Pu

However, I find this error in different places :
ca-error: Server at "http://ipa_server:9180/ca/ee/ca/profileSubmit";
replied: Invalid Request

sh-4.1# ipa user-show admin
ipa: ERROR: Missing or invalid HTTP Referer, https://ipa_server/ipa/xml

Sometimes, I also get it with "ipa cert-show 1", sometimes I don't.

Sometimes its status changes even though I don't think I've done anything :
ca-error: Server at https://ipa_server/ipa/xml failed request, will
retry: 911 (RPC failed at server.  Missing or invalid HTTP Referer,
https://ipa_server/ipa/xml).

And I can find inside /var/log/pki-ca/debug these lines :
[11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10:
signature verification enabled
[11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10
org.mozilla.jss.NoSuchTokenException
[11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10
restoring thread token
Invalid Request
        at
com.netscape.cms.profile.common.EnrollProfile.parsePKCS10(EnrollProfile.java:953)
        at
com.netscape.cms.profile.common.EnrollProfile.createRequests(EnrollProfile.java:102)
        at
com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:1001)
        at
com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:501)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at
com.netscape.cms.servlet.filter.EERequestFilter.doFilter(EERequestFilter.java:176)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
        at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
        at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
        at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        at java.lang.Thread.run(Thread.java:701)


There is the BLOB inside the logs, containing the CSR, and I can read it
with openssl so it is correctly formatted :

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: O=ipa_domain, CN=ipa_server
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a:
                    04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8:
                    77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a:
                    93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22:
                    0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e:
                    67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d:
                    53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2:
                    d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31:
                    38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6:
                    00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88:
                    f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60:
                    c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69:
                    04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30:
                    b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e:
                    0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4:
                    53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9:
                    62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28:
                    1b:fb
                Exponent: 65537 (0x10001)
        Attributes:
            friendlyName             :unable to print attribute
        Requested Extensions:
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment,
Data Encipherment
            X509v3 Subject Alternative Name:
                othername:<unsupported>, othername:<unsupported>
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                2E:41:D7:91:F0:F4:AA:F6:3D:C0:0C:6B:89:DB:23:6C:90:DA:0E:C7
    Signature Algorithm: sha256WithRSAEncryption
         53:36:9a:b6:e8:90:a1:3f:99:cf:85:64:9d:1c:ff:40:ad:f4:
         31:53:03:81:0c:37:5e:3d:d2:a2:c1:fb:1c:6c:68:f9:c8:cd:
         b9:45:38:be:b1:17:ac:63:7b:a7:46:ca:64:1a:d3:4a:c2:63:
         ca:64:ca:39:01:e4:5f:3b:6c:86:de:23:0e:12:04:be:2b:f7:
         22:1c:ac:0f:91:56:87:b2:95:20:a6:2d:10:f9:98:e5:51:46:
         c8:b0:71:20:85:98:a3:35:c4:ef:fd:55:20:5e:a9:01:ed:3b:
         99:5f:43:8a:85:b1:c7:3d:94:1d:d6:4b:87:3b:1a:72:c4:7b:
         35:5c:65:11:e2:7f:ba:72:d8:63:ab:f6:a1:6f:b0:73:0b:c5:
         c7:ca:2a:da:eb:b3:d0:64:75:7d:c3:9a:f5:b3:e7:d1:7b:e2:
         b0:ab:68:87:a2:fd:71:19:92:49:b5:e0:72:32:d8:cd:b7:f3:
         c9:a2:92:0d:20:65:c7:4a:5a:e7:d4:2a:e5:50:f1:63:44:97:
         2c:c5:27:c4:2e:38:be:4f:02:33:91:f5:7d:2d:ab:75:7b:09:
         f7:86:0d:ac:3b:b7:c9:5e:00:96:49:e4:b1:f5:19:d2:1b:e6:
         68:d6:e9:51:5b:9b:ec:d4:b3:e6:fd:e3:ee:7f:84:c3:e6:9b:
         cb:11:d8:48

And here I am, with this expired certificate still being served on my
server...

If anyone has any clue on what's going on, I would be really grateful !

Cheers,

-- 
Thibaut Pouzet
Lyra Network
Ingénieur Systèmes et Réseaux
(+33) 5 31 22 40 08
www.lyra-network.com

PS : I've tried to work with this link with no luck :
https://www.freeipa.org/page/FreeIPAv2:Certificate_Authority

-- 
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

Reply via email to