Hi,
The directory server is using a server certificate on port 636 for SSL
communications. The certificate is stored in a NSS database located in
/etc/dirsrv/slap-XXX/, with a nickname configured in
/etc/dirsrv/slap-XXX/dse.ldif:
-----
dn: cn=RSA,cn=encryption,cn=config
cn: RSA
nsSSLActivation: on
nsSSLPersonalitySSL: Server-Cert <<<< cert nickname
nsSSLToken: internal (software)
objectClass: top
objectClass: nsEncryptionModule
[...]
-----
We can find a cert with this nickname in the NSS DB:
-----
# certutil -L -d /etc/dirsrv/slapd-XXX
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u
XXX IPA CA CT,C,C
-----
In a usual setup, the nickname is "Server-Cert", but in your NSS DB I
didn't see any certificate with this nickname. I assume that the cert
nickname is "CN=*.int.i-neda.com" because it's the only one in the
database with the trust attributes u,u,u (u means that there is also a
private key associated with the certificate and the ldap server needs
access to the private key in order to use the cert as a Server Certificate).
It's totally ok to use a different nickname, as long as the
nsSSLPersonalitySSL value is the same as the nickname in the NSS DB.
Except that ipa-cert-fix doesn't take this into account and hardcodes
the nickname "Server-Cert":
You can either wait for a fix in ipa-cert-fix, or apply a workaround
which consists in renaming the certificate into "Server-Cert".
In order to do that:
Stop the LDAP server
# systemctl stop dirsrv@INT-I-NEDA-COM
Start with a backup the existing dse.ldif and NSSDB:
# cp /etc/dirsrv/slapd-INT-I-NEDA-COM/dse.ldif /path/to/backup
# cp /etc/dirsrv/slapd-INT-I-NEDA-COM/*.db /path/to/backup
Edit /etc/dirsrv/slapd-INT-I-NEDA-COM/dse.ldif and replace the
certificate nickname with Server-Cert (find the line containing
nsSSLPersonalitySSL):
nsSSLPersonalitySSL: Server-Cert
Rename the certificate in the NSSDB:
# certutil -d /etc/dirsrv/slapd-INT-I-NEDA-COM/ --rename -n <old name>
--new-n Server-Cert
Restart LDAP server
# systemctl start dirsrv@INT-I-NEDA-COM
At this point you should be able to use ipa-cert-fix.
HTH,
flo
Thanks for all the help so far, it's been much appreciated.
Kind Regards,
Marc.
-----Original Message-----
From: Florence Blanc-Renaud <flo(a)redhat.com>
Sent: 24 November 2020 10:45
To: Marc Pearson | i-Neda Ltd <mpearson(a)i-neda.com>; FreeIPA users list
<freeipa-users(a)lists.fedorahosted.org>
Subject: Re: [Freeipa-users] subsystemCert appears out of date
On 11/24/20 10:50 AM, Marc Pearson | i-Neda Ltd wrote:
> Thanks Flo,
>
> I'm suprosed I didn't catch that typeo:
>
> certutil -L -d /etc/dirsrv/slapd-INT-I-NEDA-COM
>
> Certificate Nickname Trust Attributes
>
> SSL,S/MIME,JAR/XPI
>
> CN=AddTrust External CA Root,OU=AddTrust External TTP
> Network,O=AddTrust AB,C=SE C,, CN=COMODO High-Assurance Secure Server
> CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB C,, CN=COMODO RSA Domain
Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB C,,
> comodoCA C,,
>
INT.I-NEDA.COM IPA CA CT,C,C
>
INT.I-NEDA.COM IPA CA CT,C,C
>
INT.I-NEDA.COM IPA CA CT,C,C
> CN=COMODO RSA Certification Authority,O=COMODO CA
> Limited,L=Salford,ST=Greater Manchester,C=GB C,, CN=COMODO RSA Certification
Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB C,,
> comodoCA2 C,,
>
INT.I-NEDA.COM IPA CA CT,C,C
>
INT.I-NEDA.COM IPA CA CT,C,C
> comodoCA C,,
>
CN=*.int.i-neda.com u,u,u
>
INT.I-NEDA.COM IPA CA CT,C,C
>
Ok, so I think the issue with ipa-cert-fix comes from the fact that the LDAP server cert
is not called 'Server-Cert' but rather 'CN=*.int.i-neda.com' - you can
check with the following command:
# grep nsSSLPersonalitySSL /etc/dirsrv/slapd-INT-I-NEDA-COM/dse.ldif
Can you log an issue at
https://pagure.io/freeipa/new_issue ?
When the LDAP server cert doesn't have the default name, ipa-cert-fix fails.
A possible workaround would be to rename the cert in the NSSDB to 'Server-Cert'
with certutil --rename but you will also need to update the dse.ldif file (stop ds, edit,
start ds). This will allow you to use ipa-cert-fix and hopefully to move forward.
flo
> Marc.
>
> -----Original Message-----
> From: Florence Blanc-Renaud <flo(a)redhat.com>
> Sent: 24 November 2020 09:01
> To: Marc Pearson | i-Neda Ltd <mpearson(a)i-neda.com>; FreeIPA users
> list <freeipa-users(a)lists.fedorahosted.org>
> Subject: Re: [Freeipa-users] subsystemCert appears out of date
>
> On 11/24/20 9:54 AM, Marc Pearson | i-Neda Ltd wrote:
>> Hi Flo,
>>
>> I'm getting a database error when running that command:
>>
>> # certutil -L -d /etc/dirsrc/slapd-INT-I-NEDA-COM
>> certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key
database is in an old, unsupported format.
>>
> Sorry, I made a typo, it should be dirsrv, not dirsrc:
> # certutil -L -d /etc/dirsrv/slapd-INT-I-NEDA-COM
>
> flo
>>
>> Not sure if that's of any help?
>>
>> Marc.
>>
>> -----Original Message-----
>> From: Florence Blanc-Renaud <flo(a)redhat.com>
>> Sent: 21 November 2020 19:06
>> To: Marc Pearson | i-Neda Ltd <mpearson(a)i-neda.com>; FreeIPA users
>> list <freeipa-users(a)lists.fedorahosted.org>
>> Subject: Re: [Freeipa-users] subsystemCert appears out of date
>>
>> On 11/18/20 12:23 PM, Marc Pearson | i-Neda Ltd wrote:
>>> Hi Flo,
>>>
>>> Thanks for the information. I've tried to run the cert fix utility just
now and I'm hitting an issue, ironically with the SSL certificate:
>>>
>>> [root@red-auth01 ~]# ipa-cert-fix
>>> Failed to get Server-Cert
>>> The ipa-cert-fix command failed.
>>>
>> Hi,
>> I failed to notice the first time but there is no tracking for the LDAP cert that
is stored in /etc/dirsrv/slapd-$DOMAIN/. What is the output of # certutil -L -d
/etc/dirsrc/slapd-$DOMAIN You should see Server-Cert (=the ldap server certificate), or
maybe a different nickname is used?
>>
>> flo
>>
>>> From the message log:
>>> Nov 18 11:18:32 red-auth01 dogtag-ipa-ca-renew-agent-submit:
>>> Forwarding request to dogtag-ipa-renew-agent Nov 18 11:18:32
>>> red-auth01 dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned
3 Nov 18 11:18:33 red-auth01 certmonger: 2020-11-18 11:18:33 [1164] Error 58 connecting to
https://red-auth01.int.i-neda.com:8443/ca/agent/ca/profileReview: Problem with the local
SSL certificate.
>>> Nov 18 11:18:35 red-auth01 dogtag-ipa-ca-renew-agent-submit:
>>> Forwarding request to dogtag-ipa-renew-agent Nov 18 11:18:35
>>> red-auth01 dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned
3 Nov 18 11:18:35 red-auth01 certmonger: 2020-11-18 11:18:35 [1164] Error 58 connecting to
https://red-auth01.int.i-neda.com:8443/ca/agent/ca/profileReview: Problem with the local
SSL certificate.
>>>
>>> Any advice?
>>>
>>> Marc.
>>>
>>> -----Original Message-----
>>> From: Florence Blanc-Renaud <flo(a)redhat.com>
>>> Sent: 17 November 2020 10:57
>>> To: Marc Pearson | i-Neda Ltd <mpearson(a)i-neda.com>; FreeIPA users
>>> list <freeipa-users(a)lists.fedorahosted.org>
>>> Subject: Re: [Freeipa-users] subsystemCert appears out of date
>>>
>>> On 11/17/20 10:19 AM, Marc Pearson | i-Neda Ltd wrote:
>>>> Hi Flo,
>>>>
>>>> Thanks for the help. Included is the output of all the commands as
>>>> you requested. These were all run from a single freeIPA server
(red-auth01).
>>>>
>>>> kinit admin; ipa server-role-find --role "CA server"
>>>> Password for admin(a)INT.I-NEDA.COM:
>>>> ----------------------
>>>> 8 server roles matched
>>>> ----------------------
>>>> Â Server name:
power-auth03.int.i-neda.com  Role name: CA
>>>> server  Role status: enabled
>>>>
>>>> Â Server name:
power-auth04.int.i-neda.com  Role name: CA
>>>> server  Role status: absent
>>>>
>>>> Â Server name:
red-auth01.int.i-neda.com  Role name: CA
>>>> server  Role status: enabled
>>>>
>>>> Â Server name:
red-auth02.int.i-neda.com  Role name: CA
>>>> server  Role status: enabled
>>>>
>>>> Â Server name:
red-auth03.int.i-neda.com  Role name: CA
>>>> server  Role status: enabled
>>>>
>>>> Â Server name:
red-auth04.int.i-neda.com  Role name: CA
>>>> server  Role status: enabled
>>>>
>>>> Â Server name:
white-auth01.int.i-neda.com  Role name: CA
>>>> server  Role status: enabled
>>>>
>>>> Â Server name:
white-auth02.int.i-neda.com  Role name: CA
>>>> server  Role status: enabled
>>>> ----------------------------
>>>> Number of entries returned 8
>>>> ----------------------------
>>>>
>>>>
>>>> Â kinit admin; ipa config-show | grep "renewal"
>>>> Password for admin(a)INT.I-NEDA.COM:
>>>> Â IPA CA renewal master:
red-auth01.int.i-neda.com
>>>>
>>>>
>>>> rpm -qa | grep ipa-server
>>>> ipa-server-common-4.6.8-5.el7.centos.noarch
>>>> ipa-server-4.6.8-5.el7.centos.x86_64
>>>> ipa-server-dns-4.6.8-5.el7.centos.noarch
>>>>
>>>>
>>>> getcert list
>>>> Number of certificates and requests being tracked: 8.
>>>> Request ID '20171101175244':
>>>> status: MONITORING
>>>> stuck: no
>>>> key pair storage:
type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
>>>> certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
>>>> CA: SelfSign
>>>> issuer:
CN=red-auth01.int.i-neda.com,O=INT.I-NEDA.COM
>>>> subject:
CN=red-auth01.int.i-neda.com,O=INT.I-NEDA.COM
>>>> expires: 2021-08-10 14:04:07 UTC
>>>> principal name: krbtgt/INT.I-NEDA.COM(a)INT.I-NEDA.COM
>>>> certificate template/profile: KDCs_PKINIT_Certs pre-save command:
>>>> post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
>>>> track: yes
>>>> auto-renew: yes
>>>>
>>>> Request ID '20180722081853':
>>>> status: MONITORING
>>>> stuck: no
>>>> key pair storage:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSign
>>>> i n g Cert cert-pki-ca',token='NSS Certificate DB',pin set
>>>> certificate:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSign
>>>> i n g Cert cert-pki-ca',token='NSS Certificate DB'
>>>> CA: dogtag-ipa-ca-renew-agent
>>>> issuer: CN=Certificate
Authority,O=INT.I-NEDA.COM
>>>> subject: CN=CA
Audit,O=INT.I-NEDA.COM
>>>> expires: 2022-09-16 12:36:41 UTC
>>>> key usage: digitalSignature,nonRepudiation pre-save command:
>>>> /usr/libexec/ipa/certmonger/stop_pkicad
>>>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>>>> "auditSigningCert cert-pki-ca"
>>>> track: yes
>>>> auto-renew: yes
>>>>
>>>> Request ID '20180722081854':
>>>> status: MONITORING
>>>> stuck: no
>>>> key pair storage:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigni
>>>> n g C ert cert-pki-ca',token='NSS Certificate DB',pin set
>>>> certificate:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigni
>>>> n g C ert cert-pki-ca',token='NSS Certificate DB'
>>>> CA: dogtag-ipa-ca-renew-agent
>>>> issuer: CN=Certificate
Authority,O=INT.I-NEDA.COM
>>>> subject: CN=OCSP
Subsystem,O=INT.I-NEDA.COM
>>>> expires: 2022-09-16 12:35:31 UTC
>>>> eku: id-kp-OCSPSigning
>>>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>>>> "ocspSigningCert cert-pki-ca"
>>>> track: yes
>>>> auto-renew: yes
>>>> Request ID '20180722081855':
>>>> status: CA_UNREACHABLE
>>>> ca-error: Error 58 connecting to
>>>>
https://red-auth01.int.i-neda.com:8443/ca/agent/ca/profileReview:
>>>> Problem with the local SSL certificate.
>>>> stuck: no
>>>> key pair storage:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystem
>>>> C e r t cert-pki-ca',token='NSS Certificate DB',pin set
>>>> certificate:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystem
>>>> C e r t cert-pki-ca',token='NSS Certificate DB'
>>>> CA: dogtag-ipa-ca-renew-agent
>>>> issuer: CN=Certificate
Authority,O=INT.I-NEDA.COM
>>>> subject: CN=CA
Subsystem,O=INT.I-NEDA.COM
>>>> expires: 2020-10-24 07:04:35 UTC
>>>> key usage:
>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>>> eku: id-kp-serverAuth,id-kp-clientAuth pre-save command:
>>>> /usr/libexec/ipa/certmonger/stop_pkicad
>>>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>>>> "subsystemCert cert-pki-ca"
>>>> track: yes
>>>> auto-renew: yes
>>>>
>>>> Request ID '20180722081856':
>>>> status: MONITORING
>>>> stuck: no
>>>> key pair storage:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigning
>>>> C e r t cert-pki-ca',token='NSS Certificate DB',pin set
>>>> certificate:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigning
>>>> C e r t cert-pki-ca',token='NSS Certificate DB'
>>>> CA: dogtag-ipa-ca-renew-agent
>>>> issuer: CN=Certificate
Authority,O=INT.I-NEDA.COM
>>>> subject: CN=Certificate
Authority,O=INT.I-NEDA.COM
>>>> expires: 2040-10-10 07:51:04 UTC
>>>> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>>>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>>>> "caSigningCert cert-pki-ca"
>>>> track: yes
>>>> auto-renew: yes
>>>>
>>>> Request ID '20180722081857':
>>>> status: CA_UNREACHABLE
>>>> ca-error: Error 58 connecting to
>>>>
https://red-auth01.int.i-neda.com:8443/ca/agent/ca/profileReview:
>>>> Problem with the local SSL certificate.
>>>> stuck: no
>>>> key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
>>>> certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
>>>> CA: dogtag-ipa-ca-renew-agent
>>>> issuer: CN=Certificate
Authority,O=INT.I-NEDA.COM
>>>> subject: CN=IPA
RA,O=INT.I-NEDA.COM
>>>> expires: 2020-10-24 07:03:24 UTC
>>>> key usage:
>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>>> eku: id-kp-serverAuth,id-kp-clientAuth pre-save command:
>>>> /usr/libexec/ipa/certmonger/renew_ra_cert_pre
>>>> post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
>>>> track: yes
>>>> auto-renew: yes
>>>>
>>>> Request ID '20180722081858':
>>>> status: MONITORING
>>>> stuck: no
>>>> key pair storage:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Ce
>>>> r t cert-pki-ca',token='NSS Certificate DB',pin set
>>>> certificate:
>>>>
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Ce
>>>> r t cert-pki-ca',token='NSS Certificate DB'
>>>> CA: dogtag-ipa-ca-renew-agent
>>>> issuer: CN=Certificate
Authority,O=INT.I-NEDA.COM
>>>> subject:
CN=red-auth01.int.i-neda.com,O=INT.I-NEDA.COM
>>>> expires: 2021-02-09 11:59:57 UTC
>>>> key usage:
>>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>>> eku: id-kp-serverAuth,id-kp-clientAuth,id-kp-emailProtection
>>>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>>>> "Server-Cert cert-pki-ca"
>>>> track: yes
>>>> auto-renew: yes
>>>>
>>>> Request ID '20200530130439':
>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN
>>>> stuck: yes
>>>> key pair storage:
>>>>
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert'
>>>> certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert'
>>>> CA: IPA
>>>> issuer:
>>>> subject:
>>>> expires: unknown
>>>> pre-save command:
>>>> post-save command:
>>>> track: yes
>>>> auto-renew: yes
>>>>
>>> Hi Marc,
>>>
>>> so the current situation is the following:
>>> - red-auth01 is the renewal master, with multiple replicas hosting the CA
role.
>>> - on this server, 'subsystemCert cert-pki-ca' is expired (expires:
>>> 2020-10-24 07:04:35 UTC) as well as /var/lib/ipa/ra-agent.pem (expires:
>>> 2020-10-24 07:03:24 UTC).
>>> - there is also an issue with the tracking of the cert used by HTTP
>>>
>>> But one of your comments is puzzling me:
>>>
>>>> The signing SSL (
int.i-neda.com) is a full wildcard block chain
>>>> that is authorized by a recognised 3rd party. It's worth noting
>>>> though, that we had some issues with the block chain back in April
>>>> as the thrid parties block chain expired. So it's possible that
>>>> this is as a result of that issue, and may require some fettling to
resolve. All help is appreciated.
>>> Did you import the new CA chain at that time using ipa-cacert-manage install
/ ipa-certupdate?
>>>
>>> According to getcert output, the IPA CA is now self-signed. It looks a lot
like issue
https://pagure.io/freeipa/issue/8176 where the externally-signed IPA CA is
renewed/replaced with a self-signed CA.
>>>
>>> As you have ipa 4.6.8-5, the ipa-cert-fix utility is available on your
system. It will be easier to use this tool to fix the server:
>>>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_lin
>>> u
>>> x
>>> /7/html-single/linux_domain_identity_authentication_and_policy_guide
>>> / i ndex#renewing-expired-system-certificate-when-idm-is-offline
>>>
>>> Once the systems are up again, you can switch back to an externally-signed
ipa CA:
>>> - import the external CA chain using ipa-cacert-manage install + run
>>> ipa-certupdate on all the ipa nodes
>>> - switch to externally-signed CA with ipa-cacert-manage renew
>>> --external-ca command
>>> (
https://access.redhat.com/documentation/en-us/red_hat_enterprise_li
>>> n
>>> u
>>> x/7/html-single/linux_domain_identity_authentication_and_policy_guid
>>> e
>>> /
>>> index#manual-cert-renewal-ext)
>>>
>>> HTH,
>>> flo
>>>>
>>>> My current tempory work around is to set the local clock of the OS
>>>> back by over a month so the server belives the expired CA's are still
valid.
>>>>
>>>> Kind Regards,
>>>>
>>>> Marc.
>>>> -------------------------------------------------------------------
>>>> -
>>>> -
>>>> -
>>>> --
>>>> *From:* Florence Blanc-Renaud <flo(a)redhat.com>
>>>> *Sent:* 16 November 2020 14:35
>>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
>>>> *Cc:* Marc Pearson | i-Neda Ltd <mpearson(a)i-neda.com>
>>>> *Subject:* Re: [Freeipa-users] subsystemCert appears out of date On
>>>> 11/16/20 10:03 AM, Marc Pearson | i-Neda Ltd via FreeIPA-users wrote:
>>>>> Hi All,
>>>>>
>>>>> My subsystem cert appears to have gone out of date, and
Iââ,¬â"¢m
>>>>> unable to get it to update. This has become an issue on my
>>>>> production environment, and my current work around has been to
>>>>> take the system date back by a month. Iââ,¬â"¢ve tried the
cert
>>>>> renew tool, but this doesnââ,¬â"¢t seem to have updated this
cert.
>>>>>
>>>>> Is anyone able to point me in the right direction to be able to
>>>>> update this specific certificate as Iââ,¬â"¢ve been unable to
find anything online.
>>>>>
>>>>> [auth01 ~]# certutil -L -d /etc/pki/pki-tomcat/alias -n
>>>>> 'subsystemCert cert-pki-ca'
>>>>>
>>>>> Certificate:
>>>>>
>>>>>  Ã, Ã, Ã, Data:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Version: 3 (0x2)
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Serial Number: 42 (0x2a)
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Signature Algorithm: PKCS #1
>>>>> SHA-256 With RSA Encryption
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Issuer: "CN=Certificate
Authority,O=INT.I-NEDA.COM"
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Validity:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Not Before: Sun
>>>>> Nov
>>>>> 04
>>>>> 08:04:35 2018
>>>>>
>>>>> Not After : Sat Oct 24 07:04:35 2020
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Subject: "CN=CA
Subsystem,O=INT.I-NEDA.COM"
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Subject Public Key Info:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Public Key
Algorithm:
>>>>> PKCS #1 RSA Encryption
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, RSA Public Key:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
Modulus:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
c6:7e:e6:40:8f:6e:77:07:8f:2a:ca:ca:63:63:cf:c6:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã,Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, 5f:1c:09:63:4a:bb:17:68:17:cd:20:9b:f3:b0:5b:c0:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
f7:ff:72:07:1d:a2:29:93:61:62:5c:9f:04:d3:cb:7b:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
bf:53:de:bb:dd:d6:3f:a1:14:95:04:53:64:87:73:24:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
e3:61:66:96:ab:99:1f:2c:da:ec:22:e5:21:b1:5c:d5:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
0a:dd:4e:3f:f8:e2:90:a1:55:31:ad:11:2f:3b:d3:90:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
14:dc:b7:9d:fc:35:1a:ab:48:27:68:0a:9f:cb:95:14:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
00:93:b8:d4:d4:30:de:4e:be:20:a3:01:24:e8:f2:4a:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
1a:d2:b6:e0:09:77:3d:24:e3:5a:cf:51:d6:ca:d2:65:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
53:62:72:64:fe:7d:53:09:0e:97:b8:61:c9:c8:6d:24:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
52:15:f2:bf:40:04:38:24:22:73:fb:80:a0:ff:16:57:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
e1:0b:3c:71:02:d7:e6:2e:94:0a:e7:4e:aa:5e:6f:91:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
Ã, Ã, Ã, Ã, a5:68:65:21:cd:68:0c:2d:5d:53:fa:e0:10:75:47:43:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
04:f2:8b:e1:1c:1c:ed:a6:c1:ee:5c:6c:72:51:b5:e6:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
cd:f9:06:45:17:00:2b:d7:34:75:8a:59:f2:21:97:c6:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> Ã, Ã, Ã, 63:d3:6f:54:d9:00:42:74:88:9e:94:d0:d4:d2:a1:b7
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> Exponent: 65537 (0x10001)
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Signed Extensions:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Name: Certificate
>>>>> Authority Key Identifier
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Key ID:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
f2:bb:9c:4f:e3:d8:c3:f9:58:eb:cc:5f:f7:be:8c:d6:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> d5:08:c0:3a
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Name: Authority
>>>>> Information Access
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Method: PKIX
>>>>> Online Certificate Status Protocol
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Location:
>>>>>
>>>>> Â
Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, URI:
"http://ipa-ca.int.i-neda.com/ca/ocsp"
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Name: Certificate
>>>>> Key Usage
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Critical: True
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Usages: Digital
>>>>> Signature
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> Ã, Ã, Ã, Non-Repudiation
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> Ã, Ã, Ã, Key Encipherment
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> Ã, Ã, Ã, Data Encipherment
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Name: Extended Key
>>>>> Usage
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> TLS Web Server Authentication Certificate
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> TLS Web Client Authentication Certificate
>>>>>
>>>>>  Ã, Ã, Ã, Signature Algorithm: PKCS #1 SHA-256 With RSA
>>>>> Encryption
>>>>>
>>>>>  Ã, Ã, Ã, Signature:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
5f:b7:31:25:10:ef:e7:72:44:8e:94:1d:57:4e:bb:4e:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
22:cf:9b:7e:f4:20:a2:fa:96:2a:cf:e9:70:cd:a6:82:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
4a:bd:58:4b:a7:df:4d:77:47:ba:65:d0:68:c5:dc:59:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
77:7e:bf:36:d3:55:c7:86:d3:16:77:51:46:c2:48:de:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
e8:0d:62:05:b9:8c:46:bd:22:7d:8d:d0:ad:5a:64:6b:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
9b:7d:ec:4c:e6:05:e7:02:97:cd:01:f5:19:91:15:7e:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
cc:41:5b:f2:00:2d:c0:0b:91:9e:62:d5:7a:b2:1e:8f:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
32:62:c2:ed:1a:e8:e1:56:32:e0:0e:79:55:a2:49:35:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
0e:df:5d:a3:df:e2:dd:58:60:4a:dd:19:92:f7:4d:60:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
59:0e:16:b1:ae:32:e6:c5:c5:fa:5b:2f:fe:1d:fe:e9:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
ec:67:2b:65:33:f2:57:64:8a:68:f3:91:9b:25:ff:02:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
64:4c:a1:6d:fe:f0:73:95:f2:0f:49:fb:3f:85:21:a0:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
68:37:dc:cd:73:02:73:20:22:a9:1d:c9:7e:88:4f:9b:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
7c:92:f8:c1:50:0f:95:43:48:5b:8b:7f:0f:48:04:a8:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
c7:c0:0e:58:7c:86:2c:3a:b5:72:e3:34:3d:d8:0f:26:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> eb:44:fa:75:c1:c8:fc:b6:7d:f7:31:91:a4:71:a1:51
>>>>>
>>>>>  Ã, Ã, Ã, Fingerprint (SHA-256):
>>>>>
>>>>>
>>>>>
4F:2A:1B:54:65:B6:09:3E:AD:68:08:92:CB:8D:FE:13:EF:B8:4C:F1:1E:0F:E1:
>>>>> 15:13:92:D3:7A:3D:F8:54:44
>>>>>
>>>>>  Ã, Ã, Ã, Fingerprint (SHA1):
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã,Â
>>>>> 03:34:DC:55:F5:00:AF:8C:EF:AC:AA:0D:E0:44:AD:5C:6F:CF:97:A6
>>>>>
>>>>>  Ã, Ã, Ã, Mozilla-CA-Policy: false (attribute missing)
>>>>>
>>>>>  Ã, Ã, Ã, Certificate Trust Flags:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, SSL Flags:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, User
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Email Flags:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, User
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Object Signing Flags:
>>>>>
>>>>>  Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, Ã, User
>>>>>
>>>>> Thanks for the help,
>>>>>
>>>>> Marc.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>> To unsubscribe send an email to
>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>> Fedora Code of Conduct:
>>>>>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>> List Guidelines:
>>>>>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>> List Archives:
>>>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.f
>>>>> e
>>>>> d
>>>>> o
>>>>>
rahosted.org
>>>>>
>>>> Hi Marc,
>>>>
>>>> we need more information in order to help you:
>>>> - do you have multiple master/replicas with the CA role:
>>>> # kinit admin; ipa server-role-find --role "CA server"
>>>>
>>>> - which server is the renewal master:
>>>> # kinit admin ; ipa config-show | grep "renewal"
>>>>
>>>> - which version is installed:
>>>> # rpm -qa | grep ipa-server
>>>>
>>>> - Is the subsystemCert cert-pki-ca the only expired certificate:
>>>> # getcert list
>>>>
>>>> flo
>>>>
>>>
>>
>