November 2020 - FreeIPA-users - Fedora mailing-lists

Stateless Machines and Force Join
by Mark Potter 12 Dec '20

12 Dec '20

We boot everything stateless in our environment and are using FreeIPA for authentication. I started discussing this a while ago but ended up with other things taking priority. The number of machines we have make managing keys an untenable solution so we are using ipa-client-install -U -q -p <join user> -w <password --domain=domain.com --server=ipaserver.domain.com --fixed-primary --force-join called from rc.local during boot to rejoin machines to the FreeIPA environment (we will be moving away from --fixed-primary but aren't there yet). While this works it, potentially, exposes a password. I am looking for a better way to handle machines that need to re-join at every boot. We have access to ansible as well a decent, in house, templating system for configuration. Please forgive my starting this discussion anew and not resurrecting a zombie and thanks in advance for your help! -- *Mark Potter* Senior Linux Administrator

3 5

Allocation of a new value for DNA range failed
by Ronald Wimmer 03 Dec '20

03 Dec '20

After upgrading to OL 8.1 and replacing all of my 8 IPA servers I ran into this particular problem. Is it right that I need to have an ID range where all DNA ranges have to fit in? And that the DNA range of each IPA server has to be distinct from the ranges of the other IPA servers? I will start by checking each IPA server with ldapsearch -x -D 'cn=Directory Manager' -W -b 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' (according to what Rob wrote on his blog some years ago https://rcritten.wordpress.com/2015/01/05/freeipa-and-no-dna-range/ ) Cheers, Ronald

2 7

SmartCard-HSM authentication using pinpad card reader for improved security
by Peter Steen 03 Dec '20

03 Dec '20

Hello Folks! We are working on getting smart card authentication working using pinpad card readers for improved security. To do this we use: FreeIPA Server is running on Fedora32 with latest updates. FreeIPA is also configured to be Certificate Authority. FreeIPA Clients are Fedora 32 based with latest updates with connected usb card reader Gemalto C700 with pinpad, we use several user individual SmartCard HSM 4K with FreeIPA signed certificates on them. FreeIPA Clients run OpenSC and are configured to use smartcard certificate based authentication, setup per Smartare HSM best practice. Further clients are using SSSD and not PAM_PKCS#11. All working great using smartcard for authentication, as long not enabling the pinpad in opensc. If doing so we are prompted for the PIN not only in the pinpad reader but also GDM prompts you to enter PIN on keyboard. Expected result is to be logged in directly after entering correct PIN code on pinpad reader, not being prompted by GDM to enter PIN on keyboard as well. If enabling pinpad, login gets a bit odd: 1. Fedora 32 workstation GDM menu prompts a few users that can login 2. Smartcard is inserted in reader 3. GDM blanks out the screen and smartcard reader prompts to enter PIN. 4. Entering pin on smartcard reader followed by pressing ok button on smartcard reader at getting result Pin OK in reader display. 5. GDM now prompts for entering PIN on keyboard, this is unexpected, instead of being logged in to the window manager, here Gnome or xfce. 6. Any number can be entered, it does not matter, followed by hitting enter. 7. Once again smartcard reader now prompts for PIN. 8. Entering PIN on the smartcard pinpad reader followed by pressing pinpad ok button. 9. You are now logged in, and all is normal. If ripping out the smartcard from reader the screen locks, as expected. What could this be, anyone who have seen this before or know how to set it up ?

2 6

setup ipa server with DNS when domain is managed by existing DNS server but not yet managing the reverse zones I want to configure
by Rob van Halteren 02 Dec '20

02 Dec '20

Hello, I have seen more threats like this but not exactly this topic. I am setting up an IPA server in a existing internal domain on a B-class network range . I have already a DNS server running for this domain, but it holds only a C-class network range. I tried to setup the IPA server with the "ipa-server-install --setup-dns --no-forwarders --auto-reverse --allow-zone-overlap" options but this does not work and results in the disability to create PTR records for any network range in my domain. + it than needs the existing DNS server as forwarder to be able to resolve global addresses. I intent to install the IPA server as qualified DNS server for my domain , next to the existing DNS server and when setup, decommission the existing DNS server. Any help would be appreciated Thanks. Rob.

1 1

topology question / ansible-freeipa
by Rainer Duffner 30 Nov '20

30 Nov '20

Hi, I’m trying to install FreeIPA on CentOS 8.2 with the ansible-freeipa module. After a few hiccups, it seems to work now. I want to run three masters in the end. Using the cluster-playbook, it looks like (from the Topology-Graph in the Web-GUI) that I end up with something like this: 3 < -- > 1 < -- > 2 Which seems to indicate that 3 does not talk to 2. From the documentation, it looks like I want/need replication agreements between 1+2, 1+3 and 2+3 so that if 1 is down, 2 and 3 can still be updated and talk to each other. This would - as far as I have understood the documentation - result in a playbook like this: --- - name: Add topology segments hosts: ipaserver become: true gather_facts: false vars: ipatopology_segments: - {suffix: domain+ca, left: ipa-ansible1.ipa.example.org, right: ipa-ansible2.ipa.example.org} - {suffix: domain+ca, left: ipa-ansible1.ipa.example.org, right: ipa-ansible3.ipa.example.org} - {suffix: domain+ca, left: ipa-ansible2.ipa.example.org, right: ipa-ansible3.ipa.example.org} tasks: - name: Add topology segment ipatopologysegment: ipaadmin_password: "{{ ipaadmin_password }}" suffix: "{{ item.suffix }}" name: "{{ item.name | default(omit) }}" left: "{{ item.left }}" right: "{{ item.right }}" state: checked loop: "{{ ipatopology_segments | default([]) }}“ However, when I run that, it doesn’t seem to do anything. Maybe somebody can add some information here? Rainer

2 3

ipa failed to start after reboot
by Paul-Henri Hons 30 Nov '20

30 Nov '20

Hello, I'm on Centos8 with freeipa installed from several month in lxc container (2 containers with replication). I've intalled custom certificates from letsencrypt for httpd and slapd and they're valid till january 2021. Yesterday, I restarted the containers and on both, Directory service failed to start. The log is below. Can someone help me to find the right direction to solve it ? All my services heavely depends on it :-( Thanks by advance, Paul-Henri [30/Nov/2020:08:16:06.423512539 +0000] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher AES [30/Nov/2020:08:16:06.440854922 +0000] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [30/Nov/2020:08:16:06.469627909 +0000] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher 3DES [30/Nov/2020:08:16:06.499234923 +0000] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [30/Nov/2020:08:16:06.526831242 +0000] - ERR - attrcrypt_init - All prepared ciphers are not available. Please disable attribute encryption. [30/Nov/2020:08:16:06.555048556 +0000] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher AES [30/Nov/2020:08:16:06.591310772 +0000] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [30/Nov/2020:08:16:06.653648267 +0000] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher 3DES [30/Nov/2020:08:16:06.686970459 +0000] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [30/Nov/2020:08:16:06.716504472 +0000] - ERR - attrcrypt_init - All prepared ciphers are not available. Please disable attribute encryption. [30/Nov/2020:08:16:06.773674674 +0000] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher AES [30/Nov/2020:08:16:06.807784636 +0000] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [30/Nov/2020:08:16:06.848156076 +0000] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher 3DES [30/Nov/2020:08:16:06.881073427 +0000] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [30/Nov/2020:08:16:06.910055086 +0000] - ERR - attrcrypt_init - All prepared ciphers are not available. Please disable attribute encryption. [30/Nov/2020:08:16:06.974353372 +0000] - ERR - schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [30/Nov/2020:08:16:07.039826294 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=groups,cn=compat,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.152097703 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=computers,cn=compat,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.172262353 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=ng,cn=compat,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.204863801 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target ou=sudoers,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.215156151 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=users,cn=compat,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.216821135 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.219650834 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.238011898 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.249040534 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.274750517 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.283165976 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.290449211 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.309211301 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.344580813 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.371243332 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.381258115 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.442193236 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=ad,cn=etc,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.464066203 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.479286324 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=hoah,dc=ch does not exist [30/Nov/2020:08:16:07.594646290 +0000] - WARN - NSACLPlugin - acl_parse - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [30/Nov/2020:08:16:07.629034110 +0000] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=hoah,dc=ch--no CoS Templates found, which should be added before the CoS Definition. [30/Nov/2020:08:16:07.651839151 +0000] - ERR - ipalockout_get_global_config - [file ipa_lockout.c, line 178]: krb5_init_context failed (-1429577697) [30/Nov/2020:08:16:07.685167130 +0000] - ERR - ipaenrollment_start - [file ipa_enrollment.c, line 398]: krb5_init_context failed [30/Nov/2020:08:16:07.713369817 +0000] - ERR - ipapwd_start - [file ipa_pwd_extop.c, line 1857]: krb5_init_context failed

2 2

ipa-client-automount server query
by Scott Dungan 27 Nov '20

27 Nov '20

When attempting to setup a domain client to query the domain for automounts, we see the following: ipa-client-automount --location=default Searching for IPA server... Autodiscovery was successful but didn't return a server If we specify a server it works: ipa-client-automount --location=default --server idm1.domain.com IPA server: idm1.domain.com Location: default Continue to configure the system with these values? [no]: This implies that the client will only query this server for automount entries, rather than all IPA replicas, so therefore it is not a redundant configuration. My question is how to populate DNS entries so that the command can find the server(s) automatically. We are using an external DNS service, so this may explain why the command is unable to find automount servers?

2 3

Re: subsystemCert appears out of date
by Florence Blanc-Renaud 27 Nov '20

27 Nov '20

On 11/27/20 11:54 AM, Marc Pearson | i-Neda Ltd wrote: > Hi Flo, > > I've raised that issue as requested including this full email chain so far: > > https://pagure.io/freeipa/issue/8600 > > Sorry to seem dense, but ssl certs and keys are definatly not my strong suite, and the whole freeipa setup se have was sort of dumped on me when my colleague who was looking after this left the company. Would you be able to be a bit more specific on what I need to do to try and work around this issue, or point me in the correct direction so that I'm able figure out (and hopefully learn more of the freeipa workings) the steps to attempt this work around. > 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": https://pagure.io/freeipa/blob/master/f/ipaserver/install/ipa_cert_fix.py#_… 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 >>>>> >>>> >>> >> >

1 0

Re: subsystemCert appears out of date
by Florence Blanc-Renaud 27 Nov '20

27 Nov '20

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='auditSigni >>>> n g Cert cert-pki-ca',token='NSS Certificate DB',pin set >>>> certificate: >>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigni >>>> 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='ocspSignin >>>> g C ert cert-pki-ca',token='NSS Certificate DB',pin set >>>> certificate: >>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSignin >>>> 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='subsystemC >>>> e r t cert-pki-ca',token='NSS Certificate DB',pin set >>>> certificate: >>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemC >>>> 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='caSigningC >>>> e r t cert-pki-ca',token='NSS Certificate DB',pin set >>>> certificate: >>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningC >>>> 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-Cer >>>> t cert-pki-ca',token='NSS Certificate DB',pin set >>>> certificate: >>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cer >>>> 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_linu >>> 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_lin >>> u >>> x/7/html-single/linux_domain_identity_authentication_and_policy_guide >>> / >>> 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.fe >>>>> 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 >>>> >>> >> >

2 1

Auditing FreeIPA activities
by Sreenadh Menon 26 Nov '20

26 Nov '20

Hi, As part of auditing certain activities such as "User Add" "Group Add" and other modifications, we are trying to setup a tool such as Splunk. When a user gets added or any modification is made in FreeIPA we need to Audit who made that change. But FreeIPA seems to be not logging that particular information, Would like to know if any one here have achieved that here. I noticed the following option, https://github.com/pschiffe/rsyslog-elasticsearch-kibana My understanding is this is a preconfigured Kibana setup where we need to forward all the FreeIPA related logs to this Kibana docker through rsyslog. As per the following image, https://github.com/pschiffe/rsyslog-elasticsearch-kibana/blob/master/doc/im… The user who is making the change also is getting logged. For example, we can see that the action "user_add" was committed by the user, admin@KVM. From my research this does not seem to be a Kibana Action as such, but something that is present in the FreeIPA log file. How ever I could not find the string user_add itself anywhere in the log after adding the user. I checked the logs such as, slapd-$REALM/access Is it because the FreeIPA logs have changed over the years and this solution is no longer usable, or is it something entirely generated by Kibana and we can use it with the newer FreeIPA versions as well> Sorry for the long post. Thanks in advance!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users November 2020