On 10/28/2017 01:15 AM, Kristian Petersen via FreeIPA-users wrote:
I forgot to include the results of the commands in case it is helpful:Hi,
-bash-4.2$ ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso description: 2;4;CN=Certificate Authority,O=CHEM.BYU.EDU <http://CHEM.BYU.EDU>;CN=CA Subsystem,O=CHE
Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate:: MIIDdTCCAl2gAwIBAgIBBDANBgkqhkiG9w0BAQsFADA3MRUwEwYDVQQKDAxD
SEVNLkJZVS5FRFUxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAe Fw0xNTEwMTMyMDUwM
jhaFw0xNzEwMDIyMDUwMjhaMC4xFTATBgNVBAoMDENIRU0uQllVLkVEVTEVM BMGA1UEAwwMQ0EgU3
Vic3lzdGVtMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtW9NKg tthoustZq+bobtAe+
z8z82YinNVC9YzOejrRqRHST4ZiJIq2S6pGPUxbDcpit9eBgyjBT5Ale2B1B SN+SfKcBeK+AMjYF0
sBM9Aplx/wBu0IIyA4owqw0QxhtSpvTFEAPZ15JJEb5Rakgl/Gb19+GIzt7F R2t6xtozPFjlzH5HX
Npiocdl7RvF6UjktsnE/0N5T/8aBPQbunECePUakskUjr0Cv1HjIKsERXtTn 0HAc5ETitHkbCCxn+
8oT082PzDmD1gPgtTI86bsuqcJIHVSqVCk3dIRBL0OLeD3tHkfIp4o+NuoAY aWi/hjpgq0ZXa2zM8
zIy33h+A+UQIDAQABo4GUMIGRMB8GA1UdIwQYMBaAFB0PNWo+emloojFyMjH rItpaAfVCMD8GCCsG
AQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2lwYTEuY2hlbS5ieXUu ZWR1OjgwL2NhL29jc
3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFB QcDAjANBgkqhkiG9w
0BAQsFAAOCAQEAnsZeWq5e0UWJwaJqTiJdm+1jvQJrzOPWRYPfu9MTpfFjyh lNEwMX0azVzTrFbn2
7+JjQpcxH60zNurhjfavdx3S+/Dmz0dZPgX6AKBeZMfKyyfLeXaoCz3AW9uI biQZZFdQloGGB82Ek
M78W6rJVxb5x9Juck4D4GaeqOuHgNPYVnpNkWR4shCnbGdGjrG4kQRO4I91D xYBrKnY8Fmucxq2y1
4Xi29RT9Plx6p4g4E+LjqdZVAPlK/x3IQDxL2Shp/ycQxGEjfmPX8t3gbyi9 e4QvHv5EdmrGpHlIQ
bicsPmJ3gmDLn+EcIyoxpT7BLmJKPrn0FjF+FTyE/OrzHBkg==
M.BYU.EDU <http://M.BYU.EDU>
seeAlso: CN=CA Subsystem,O=CHEM.BYU.EDU <http://CHEM.BYU.EDU>
-bash-4.2$ sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIBMDANBgkqhkiG9w0BAQsFADA3MRUwEwYDVQQKDAxD SEVN
LkJZVS5FRFUxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0x NzA5
MDQyMDUwNThaFw0xOTA4MjUyMDUwNThaMC4xFTATBgNVBAoMDENIRU0uQllV LkVE
VTEVMBMGA1UEAwwMQ0EgU3Vic3lzdGVtMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8A
MIIBCgKCAQEAtW9NKgtthoustZq+bobtAe+z8z82YinNVC9YzOejrRqRHST4 ZiJI
q2S6pGPUxbDcpit9eBgyjBT5Ale2B1BSN+SfKcBeK+AMjYF0sBM9Aplx/wBu 0IIy
A4owqw0QxhtSpvTFEAPZ15JJEb5Rakgl/Gb19+GIzt7FR2t6xtozPFjlzH5H XNpi
ocdl7RvF6UjktsnE/0N5T/8aBPQbunECePUakskUjr0Cv1HjIKsERXtTn0HA c5ET
itHkbCCxn+8oT082PzDmD1gPgtTI86bsuqcJIHVSqVCk3dIRBL0OLeD3tHkf Ip4o
+NuoAYaWi/hjpgq0ZXa2zM8zIy33h+A+UQIDAQABo4GTMIGQMB8GA1UdIwQY MBaA
FB0PNWo+emloojFyMjHrItpaAfVCMD4GCCsGAQUFBwEBBDIwMDAuBggrBgEF BQcw
AYYiaHR0cDovL2lwYS1jYS5jaGVtLmJ5dS5lZHUvY2Evb2NzcDAOBgNVHQ8B Af8E
BAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3 DQEB
CwUAA4IBAQC3eGtIqHewdEtW7EagaUGkc4LoCulmhhmTC7lxOYYT+ADBrve6 RSOA
UpXSNCoetQU0QmXQkEXDtaZpjYFV2DaniwoAB6HuyG7do/BYdJoX8vKP/vCo JJCJ
V64BuCE/uipYclGXbKZPkElbfASIAiNa6X+pSvhIqdTHS0dE7DpHK+ m7sIlb1AO0
yVmCZBIh1OT/sKajOaLA7epksAA1c9M0BSkdgjrIxAKaeHTtadnLPDEGVQor 357Z
yPyQ+vSM6GNI/Z02z+paX7WxuI/uZRHzD2MoprmUCfv03isv66EUu0EVox3w SEBT
zXGp0EVo/JHfrENJKzszJ4qWGhXJfyII
-----END CERTIFICATE-----
-bash-4.2$
so it looks like the certificate 'subsystemCert cert-pki-ca' has been renewed, stored in /etc/pki/pki-tomcat/alias but not copied into the LDAP server.
The most recent version is the one in /etc/pki/pki-tomcat/alias (we can see that by comparing the serial numbers) and needs to be put into the LDAP entry. You can perform this using ldapmodify tool or a graphical LDAP browser.
With ldapmodify:
1/ extract the certificate from /etc/pki/pki-tomcat/alias into a single line, without the -----BEGIN CERTIFICATE---- and -----END CERTIFICATE----- delimiters:
$ sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a | tail -n +2 | head -n -1 | tr -d '\r\n'
MIIDdDCC...WGhXJfyII
(tail -n +2 removes the -----BEGIN CERTIFICATE----- and head -n -1 removes the -----END CERTIFICATE-----, while tr -d '\r\n' deletes new line and return characters).
2/ Find the certificate serial number
sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep Serial
Serial Number: 48 (0x30)
2/ perform ldapmodify with the value obtained above:
ldapmodify -x -D 'cn=directory manager' -W
dn: uid=pkidbuser,ou=people,o=ipaca
changetype: modify
replace: usercertificate
usercertificate:: <PASTE output from above step 1 here>
-
replace: description
description: 2;48;CN=Certificate Authority,O=CHEM.BYU.EDU,;CN=CA Subsystem,O=CHEM.BYU.EDU
(do not forget to type return twice to send the modify command).
In my example, the description field contains "48" as it is the serial number of the new subsystemCert cert-pki-ca obtained in the step 2.
After that, you should be able to restart pki-tomcatd. Please tell me if you still encounter issues,
Flo.
On Fri, Oct 27, 2017 at 5:08 PM, Kristian Petersen <nesretep@chem.byu.edu <mailto:nesretep@chem.byu.edu>> wrote: <nesretep@chem.byu.edu <mailto:nesretep@chem.byu.edu>
I also found that the certs don't match! LDAP and certutil return
different certs when you query them. The blog post didn't suggest a
method for fixing this and I don't want to make the problem worse by
doing it the wrong way. Suggestions?
On Fri, Oct 27, 2017 at 1:35 PM, Kristian Petersen> wrote:
I followed some of the steps outlined in the blog post you liked
to and when I got to the part where make sure that the private
key can be read using the password found in
/var/lib/pki/pki-tomcat/conf/password.conf using:
sudo certutil -K -d /etc/pki/pki-tomcat/alias -f
/tmp/pwdfile.txt -n 'subsystemCert cert-pki-ca'
RESULT:
certutil: Checking token "NSS Certificate DB" in slot "NSS User
Private Key and Certificate Services"
certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID:
Unrecognized Object Identifier.
So it looks like things aren't associated properly anymore. Not
sure what my next steps would be though.
On Fri, Oct 27, 2017 at 10:27 AM, Florence Blanc-Renaud<mailto:jochen@jochen.org <mailto:jochen@jochen.org>>><flo@redhat.com <mailto:flo@redhat.com>> wrote:
On 10/27/2017 12:55 AM, Kristian Petersen via FreeIPA-users
wrote:
I checked the logs that turned up after running the find
command suggested by Jochen and only a couple of them
turned up anything that mention pki or pki-tomcat:
from /var/log/audit/audit.log:
type=SERVICE_START msg=audit(1508873851.623:163448):
pid=1 uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:init_t:s0
msg='unit=pki-tomcatd@pki-tomcat comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=?
terminal=? res=failed'
from /var/log/messages:
Oct 26 16:01:58 ipa1 ns-slapd:
[26/Oct/2017:16:01:58.077129423 -0600] - ERR -
slapi_ldap_bind - Error: could not bind id
[cn=Replication Manager
cloneAgreement1-ipa2.chem.byu.edu-pki-tomcat,ou=csusers,cn=c onfig]
authentication mechanism [SIMPLE]: error 32 (No such object)
Oct 26 16:01:58 ipa1 named-pkcs11[16463]: client
192.168.105.11#37937: request has invalid signature:
TSIG DHCP_UPDATER: tsig verify failure (BADKEY)
Hi,
just a wild guess, but we saw issues during update related
either to certificates or IPv6.
- Is IPv6 enabled on your server? The server doesn't need an
IPv6 address but IPv6 should not be disabled.
- If selinux is in enforcing mode, there were known issues
during certificate renewals that could lead to pki-tomcat
not able to start any more. You can refer to this blog post
[1] to check that the certificate 'subsystemCert
cert-pki-ca' is properly associated to the user
uid=pkidbuser,ou=people,o=ipaca. The certificate is stored
in multiple places (ldap server, nss dbs) and must be
consistent.
Flo
[1]
https://floblanc.wordpress.com/2017/09/11/troubleshooting- freeipa-pki-tomcatd-fails-to- start/
<https://floblanc.wordpress.com/2017/09/11/troubleshooting- >freeipa-pki-tomcatd-fails-to- start/
On Thu, Oct 26, 2017 at 2:32 PM, Jochen Hein
<jochen@jochen.org <mailto:jochen@jochen.org>
wrote:
Kristian Petersen via FreeIPA-users
<freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org >
<mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fe
<mailto:freeipa-users@lists.fedorahosted.org >>> writes:
> The dirsrv log just shows a bunch of the following:
> [13/Oct/2017:14:32:07.132312021 -0600] - ERR -
slapi_ldap_bind - Error:
> could not bind id [cn=Replication Manager
cloneAgreement1-ipa
> 2.chem.byu.edu-pki-tomcat,ou=csusers,cn=config]
authentication mechanism
> [SIMPLE]: error 32 (No such object)
>
> That makes sense though since pki-tomcat won't
start. Rob was asking what
> was in the logs located at
/var/log/pki/pki-tomcat/ca/debug, but that path
> doesn't exist on any of my IPA servers. He said
that would normally be the
> first place to look. Hence, I am looking for
other solutions.
Brute force: reproduce the error and run "find
/var/log -mmin -1
-type f -ls".
This finds the files changed in the last minute -
one of these might
help.
Jochen
--
This space is intentionally left blank.
-- Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry
_______________________________________________
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org dorahosted.org >
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org >
-- Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry
-- Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry
--
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org