[Pki-users] pki 10.5 - Unable to log in to PKI console
Marc Sauton
msauton at redhat.com
Tue Feb 18 01:11:46 UTC 2020
Extra note, a ldapmodify "replace" should be used as the userCertificate
can be multi valued, and the first sample may be used from a LDAP search
result set, which can be the older certificate, so it is better to either
del/add or replace it to avoid confusion.
Thanks,
M.
On Mon, Feb 17, 2020 at 5:05 PM Marc Sauton <msauton at redhat.com> wrote:
> For the pkiconsole:
> correct for RHEL, would need the RHCS subscription.
> but it is available from Fedora:
> pki-console-10.7.3-3.fc31.noarch : PKI Console Package
> Repo : fedora
>
> I do not think we have the pkiconsole in CentOS (
> http://mirror.centos.org/centos/7.7.1908/ )
>
> For the ldapmodify, add the colon char twice because the value is already
> base-64 encoded, like for example:
>
> dn: uid=caadmin,ou=people,dc=ca,dc=risd,dc=org
> changetype: modify
> delete: userCertificate
> -
> add: userCertificate
> userCertificate:: MII...
>
> That should solve the issue!
>
> Thanks,
> M.
>
> On Mon, Feb 17, 2020 at 3:13 PM Wolf, Brian <Brian.Wolf at risd.org> wrote:
>
>> Marc-
>>
>>
>>
>> You were correct that the directory manager had the serial #6 version. I
>> tried to replace it with the #33 version, but now when I try to connect, I
>> get the error “You did not provide a valid certificate for this operation.”
>> Instead of “Invalid credential.”
>>
>>
>>
>> First, you mentioned using pkiconsole. I don’t have pkiconsole installed.
>> I think we found that that was part of RHCS, and we don’t have a
>> subscription for RHCS. So I’m just wading through the CLI commands.
>>
>>
>>
>> Also, I didn’t find any naming contexts specifically referencing the
>> instance. Caadmin showed up in the Agents and Administrators queries for
>> dc=ca,dc=risd,dc=org.
>>
>>
>>
>> And there is no CN=PKI Administrator entry in the list of Administrators.
>>
>>
>>
>>
>>
>> # ldapsearch -xLLL -D "cn=Directory Manager" -W -b "" -s base
>> namingcontexts
>>
>> Enter LDAP Password:
>>
>> dn:
>>
>> namingcontexts: dc=ca,dc=risd,dc=org
>>
>> namingcontexts: dc=risd,dc=org
>>
>>
>>
>> # ldapsearch -xLLL -D "cn=directory manager" -W -b
>> ou=groups,dc=risd,dc=org cn=*Agents dn uniqueMember
>>
>> Enter LDAP Password:
>>
>> [root at risdca1 tmp]#
>>
>>
>>
>>
>>
>> # ldapsearch -xLLL -D "cn=directory manager" -W -b
>> ou=groups,dc=ca,dc=risd,dc=org cn=*Agents dn uniqueMember
>>
>> Enter LDAP Password:
>>
>> dn: cn=Certificate Manager Agents,ou=groups,dc=ca,dc=risd,dc=org
>>
>> uniqueMember: uid=caadmin,ou=People,dc=ca,dc=risd,dc=org
>>
>> uniqueMember: uid=pkidbuser,ou=People,dc=ca,dc=risd,dc=org
>>
>>
>>
>> dn: cn=Registration Manager Agents,ou=groups,dc=ca,dc=risd,dc=org
>>
>>
>>
>> # ldapsearch -xLLL -D "cn=directory manager" -W -b
>> ou=groups,dc=ca,dc=risd,dc=org cn=*Administrators dn uniqueMember
>>
>> Enter LDAP Password:
>>
>> dn: cn=Administrators,ou=groups,dc=ca,dc=risd,dc=org
>>
>> uniqueMember: uid=caadmin,ou=People,dc=ca,dc=risd,dc=org
>>
>> uniqueMember: uid=xxxxx,ou=People,dc=ca,dc=risd,dc=org
>>
>>
>>
>> dn: cn=Security Domain Administrators,ou=groups,dc=ca,dc=risd,dc=org
>>
>> uniqueMember: uid=caadmin,ou=People,dc=ca,dc=risd,dc=org
>>
>>
>>
>> dn: cn=Enterprise CA Administrators,ou=groups,dc=ca,dc=risd,dc=org
>>
>> uniqueMember: uid=caadmin,ou=People,dc=ca,dc=risd,dc=org
>>
>> uniqueMember: uid=xxxxx,ou=People,dc=ca,dc=risd,dc=org
>>
>>
>>
>> dn: cn=Enterprise KRA Administrators,ou=groups,dc=ca,dc=risd,dc=org
>>
>> uniqueMember: uid=caadmin,ou=People,dc=ca,dc=risd,dc=or
>>
>>
>>
>>
>>
>>
>>
>> The user certificate appeared to be in X509 format. I copied that to a
>> file and verified that it was the expired #6 version.
>>
>>
>>
>> # ldapsearch -xLLL -D "cn=directory manager" -W -b
>> ou=people,dc=ca,dc=risd,dc=org uid=caadmin userCertificate
>>
>> Enter LDAP Password:
>>
>> dn: uid=caadmin,ou=people,dc=ca,dc=risd,dc=org
>>
>> userCertificate::
>> MII********************************************************
>>
>>
>> S***************************************************************************
>>
>>
>> G***************************************************************************
>>
>> …
>>
>>
>> **********************************************************************M7nQ==
>>
>>
>>
>> I didn’t find any examples of multi-line values in the ldapmodify file,
>> so I tried using the same format as the search used, with the second and
>> subsequent lines beginning with a space and a “-“ on the last line.
>>
>>
>>
>>
>>
>> $ cat ldapmodify.caadmin.txt
>>
>> dn: uid=caadmin,ou=people,dc=ca,dc=risd,dc=org
>>
>> changetype: modify
>>
>> replace: userCertificate
>>
>> userCertificate:
>> MII*********************************************************
>>
>>
>> S****************************************************************************
>>
>> …
>>
>>
>> P***********************************************************************mDw==
>>
>> -
>>
>>
>>
>> # ldapmodify -x -D "cn=directory manager" -W -f
>> /tmp/ldapmodify.caadmin.txt
>>
>> Enter LDAP Password:
>>
>> modifying entry "uid=caadmin,ou=people,dc=ca,dc=risd,dc=org"
>>
>> #
>>
>>
>>
>> # ldapsearch -xLLL -D "cn=directory manager" -W -b
>> ou=people,dc=ca,dc=risd,dc=org uid=caadmin userCertificate
>>
>> Enter LDAP Password:
>>
>> dn: uid=caadmin,ou=people,dc=ca,dc=risd,dc=org
>>
>> userCertificate:
>> MII****************************************************************************
>>
>>
>> V******************************************************************************************
>>
>> ….
>>
>>
>> K***********************************************************************************mdw==
>>
>>
>>
>>
>>
>> So it took what I gave it. I noticed that for the old cert, ldapsearch
>> displayed “userCertificate::” (two colons), and now it only has
>> “userCertificate:” (one colon). Is that significant? I tried changing the
>> input file to read userCertificate::, and then ldapsearch showed both
>> colons again, but I still got the “you did not provide a valid credential…”
>> error when I tried to connect from my laptop.
>>
>>
>>
>>
>>
>> I verified that Firefox on my laptop is using PKI Administrator [33] for
>> identification.
>>
>>
>>
>> - Brian
>>
>>
>>
>>
>>
>> *From:* Marc Sauton <msauton at redhat.com>
>> *Sent:* Monday, February 17, 2020 2:00 PM
>> *To:* Wolf, Brian <Brian.Wolf at risd.org>
>> *Cc:* pki-users at redhat.com
>> *Subject:* Re: [Pki-users] pki 10.5 - Unable to log in to PKI console
>>
>>
>>
>> The entry
>>
>> CN=PKI Administrator,E=caadmin at MyServer.MyDomain,OU=MyInstance,O=MyDomain
>>
>> likely has the older cert with serial 6, it just needs the newer one with
>> serial 0x33 / 51
>>
>> It may be easier to use the pkiconsole to add it, under"
>>
>> "Configuration | Users and Groups | Users | admin | Certificates | Import"
>>
>> Thanks,
>>
>> M.
>>
>>
>>
>> On Mon, Feb 17, 2020 at 11:50 AM Marc Sauton <msauton at redhat.com> wrote:
>>
>> Hello,
>>
>> Probably either there is no caadmin (uid=admin may set from the older
>> environment), or the SSL client certificate is simply missing from the
>> administrator or agent groups.
>>
>> Try for example:
>>
>>
>>
>> locate the LDAP base DN of the PKI repository:
>>
>> ldapsearch -xLLL -D "cn=directory manager" -W -b "" -s base
>> namingcontexts
>>
>>
>>
>> output example:
>>
>> dn:
>> namingcontexts: dc=example,dc=test
>> namingcontexts: o=rootca1-CA
>>
>> namingcontexts: o=subca1-CA
>>
>>
>>
>> note it could be also in the form of namingcontexts:
>> dc=ca1.example.test-pki-ca1
>>
>> and in your case it may be similar to o=risd-ise-CA
>>
>>
>>
>> then search into that LDAP backend to verify the values of the attribute
>> uniquemember of the entries, like as this example but by replacing the
>> string o=subca1-CA to match your environment:
>>
>> either for the agent users:
>>
>> ldapsearch -xLLL -D "cn=directory manager" -w password -b
>> ou=groups,o=subca1-CA cn=*Agents dn uniqueMember
>>
>> or the administrators (admin or caadmin is the default one, like a "root"
>> user):
>>
>> ldapsearch -xLLL -D "cn=directory manager" -w password -b
>> ou=groups,o=subca1-CA cn=*Administrators dn uniqueMember
>>
>>
>>
>> then verify the uniqueMember value correspond to a valid existing LDAP
>> entry, like for example:
>>
>> dn: uid=caadmin,ou=people,o=subca1-CA
>>
>>
>>
>> and then verify that admin or agent user entry has a corresponding user
>> certificate, like for example:
>>
>> ldapsearch -LLLx -D "cn=directory manager" -W -b
>> ou=people,o=subca1-CA uid=caadmin userCertificate
>>
>>
>>
>> you may have to update the value of the userCertificate with ldapmodify
>> to match the certificate with serial number 0x33 and subject DN
>>
>> CN=PKI Administrator,E=caadmin at MyServer.MyDomain,OU=MyInstance,O=MyDomain
>>
>> from the NSS db at ~/.dogtag/risd-ise/ca/alias/
>>
>>
>>
>> Note this can be done using the pkiconsole.
>>
>>
>>
>> Thanks,
>>
>> M.
>>
>>
>>
>> On Mon, Feb 17, 2020 at 9:41 AM Wolf, Brian <Brian.Wolf at risd.org> wrote:
>>
>> I installed PKI-CA several years ago on a Redhat 7 (actually Oracle
>> Unbreakable Linux) server. I used it to create certificates for an
>> application and have not really used it since. I had to renew the base
>> certificates last year. That took some effort, but I got it to work. Now I
>> am unable to connect to the web-based agent page. I copied the PKI
>> Administrator .p12 certificate from ~/.dogtag/MyInstance/ to my laptop and
>> installed it under “Your Certificates and the signing certificate under
>> Authorities in Firefox. When I try to connect to the agent page (
>> https://.../ca/agent/ca), the padlock goes green, but I get an “Invalid
>> Credential” error. /var/log/pki/risd-ise/ca/system contains
>>
>>
>>
>> Cannot authenticate agent with certificate Serial 0x33 Subject DN CN=PKI
>> Administrator,E=caadmin at MyServer.MyDomain,OU=MyInstance,O=MyDomain.
>> Error: User not found
>>
>>
>>
>> The caadmin cert is in ~/.dogtag/risd-ise/ca/alias/cer8.db. There are
>> actually two entries- the current one and the previous expired one. It is
>> also in /etc/pki/ca-trust/source/anchors
>>
>>
>>
>>
>>
>> What it is looking for and where?
>>
>>
>>
>>
>>
>> - Brian
>>
>>
>>
>>
>>
>>
>>
>> # certutil -L -d ~/.dogtag/MyInstance/ca/alias
>>
>>
>>
>> Certificate Nickname Trust
>> Attributes
>>
>>
>> SSL,S/MIME,JAR/XPI
>>
>>
>>
>> CA Signing Certificate - MyDomain CT,c,
>>
>> caadmin u,u,u
>>
>> caadmin u,u,u
>>
>>
>>
>>
>>
>> # certutil -L -d ~/.dogtag/MyInstance/ca/alias -n caadmin
>>
>> Certificate:
>>
>> Data:
>>
>> Version: 3 (0x2)
>>
>> Serial Number: 51 (0x33)
>>
>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>>
>> Issuer: "CN=CA Signing Certificate,OU=MyInstance,O=MyDomain"
>>
>> Validity:
>>
>> Not Before: Tue Feb 26 04:20:43 2019
>>
>> Not After : Wed Feb 26 04:20:43 2020
>>
>> Subject: "CN=PKI Administrator,E=caadmin at MyServer.MyDomain
>> ,OU=MyInstance
>>
>> ,O=MyDomain"
>>
>> Subject Public Key Info:
>>
>>
>>
>>
>>
>> Certificate:
>>
>> Data:
>>
>> Version: 3 (0x2)
>>
>> Serial Number: 6 (0x6)
>>
>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>>
>> Issuer: "CN=CA Signing Certificate,OU=MyInstance,O=MyDomain"
>>
>> Validity:
>>
>> Not Before: Fri Mar 10 22:38:25 2017
>>
>> Not After : Thu Feb 28 22:38:25 2019
>>
>> Subject: "CN=PKI Administrator,E=caadmin at MyServer.MyDomainr
>> ,OU=MyInstance
>>
>> ,O=MyDomain"
>>
>> Subject Public Key Info:
>>
>> Public Key Algorithm: PKCS #1 RSA Encryption
>>
>> RSA Public Key:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> # certutil -L -d /etc/pki/ca-trust/source/anchors -n "PKI Administrator -
>> MyDomain"
>>
>> Certificate:
>>
>> Data:
>>
>> Version: 3 (0x2)
>>
>> Serial Number: 51 (0x33)
>>
>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>>
>> Issuer: "CN=CA Signing Certificate,OU=MyInstance,O=MyDomain"
>>
>> Validity:
>>
>> Not Before: Tue Feb 26 04:20:43 2019
>>
>> Not After : Wed Feb 26 04:20:43 2020
>>
>> Subject: "CN=PKI Administrator,E=caadmin at MyServer.MyDomain
>> ,OU=MyInstance
>>
>> ,O=MyDomain"
>>
>> Subject Public Key Info:
>>
>> Public Key Algorithm: PKCS #1 RSA Encryption
>>
>> RSA Public Key:
>>
>> Modulus:
>>
>>
>>
>> Current versions:
>>
>>
>>
>> Current versions:
>>
>>
>>
>> Linux 4.14.35-1902.10.7.el7uek.x86_64 #2 SM
>>
>>
>>
>> pki-base-10.5.16-6
>>
>> pki-base-java-10.5.16-6.el7_7.noarch
>>
>> java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pki-users mailing list
>> Pki-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-users/attachments/20200217/c8c3940f/attachment.htm>
More information about the Pki-users
mailing list