Stage user is not recognized without objectClass posixaccount
by Dmitry Perets
Hi,
I observe a weird problem, trying to figure out how it could happen...
On one of my IPA installations, IPA doesn't recognize stage users, UNLESS they include objectClass posixaccount.
For example, below output shows a staged user that I've manually added with "ldapmodify", but as you can see, it is not found with "ipa stageuser-find":
```
$ ldapsearch -Y GSSAPI uid=atest
SASL/GSSAPI authentication started
SASL username: admin(a)IMS.DCN.EXAMPLE.DE
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ims,dc=dcn,dc=example,dc=de> (default) with scope subtree
# filter: uid=atest
# requesting: ALL
#
# atest, staged users, accounts, provisioning, ims.dcn.example.de
dn: uid=atest,cn=staged users,cn=accounts,cn=provisioning,dc=ims,dc=dcn,dc=ex
ample,dc=de
objectClass: top
objectClass: inetorgperson
objectClass: organizationalPerson
objectClass: person
uid: atest
sn: atest
givenName: atest
cn: atest
# search result
search: 4
result: 0 Success
# numResponses: 2
# numEntries: 1
```
```
$ ipa stageuser-find
WARNING: yacc table file version is out of date
---------------
0 users matched
---------------
----------------------------
Number of entries returned 0
----------------------------
```
This user will be recognized, if I add the following attributes:
objectClass: posixaccount
uidNumber: -1
gidNumber: -1
homeDirectory: /home/atest
But this is not supposed to be so... and in fact, on another IPA installation (totally separate) I don't see this constraint. The same LDIF (just different base DN) gets properly recognized as staged user!
I was comparing the entire cn=config and the IPA server configuration section, but I cannot find what setting can possibly affect this...
Can you help with an idea please?
2 years, 11 months
Is it possible to define the default ClientAliveInterval in FreeIPA
by Milos Cuculovic
Hi all,
I’m using FreeIPA to manage the Ubuntu server users mostly for SSH login purposes.
Is it possible to define a default ClientAliveInterval in FreeIPA, the same parameter that is available in /etc/ssh/sshd_config file?
The goal being to have a default interval limit for all FreeIPA user sessions on the server. The configuration is basic, using erberos and SSSD.
Looking forward to hearing from you.
Milos
2 years, 11 months
Password reset
by Yuri Krysko
Hello All,
I am familiar with the approach laid out in https://www.freeipa.org/page/Self-Service_Password_Reset and how we should use 3rd-party password reset tools. I’d like to clarify why the Change Password link is present in user’s profile, as well as admin users may try to reset their password from Active Users -> <user> -> Actions -> Reset Password. Also, there’s a way to grant, as I understand it, write access to various password-related attributes via RBAC -> Self Service Permissions, which should enable users to update these attributes. Could someone please clarify if I should be able to change my own password using UI considering the above?
Thanks,
Yuri
________________________________
LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this e-mail and any files transmitted with it to be protected, proprietary or privileged information intended solely for the use of the named recipient(s). Any disclosure of this material or the information contained herein, in whole or in part, to anyone outside of the intended recipient or affiliates is strictly prohibited. M. C. Dean, Inc. accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of the information contained in it, unless that information is subsequently confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to infringe on any rights of the recipient; any such communication violates company policy. If you are not the intended recipient, any disclosure, copying, distribution, or action taken or omitted in reliance on this information is strictly prohibited by M.C. Dean, Inc.; please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
2 years, 11 months
Get username and password via bind preop plugin in FreeIPA
by Elena Fedorov
Hello,
I have FreeIPA version 4.6.4, api_version 2.229
The system supports sasl bind version 3, mech GSSAPI.
I need to support logon from the front end for users who are not part of
the FreeIPA directory server.
For such users I will need to bind as a predefined existing Free IPA
account.
The problem is I can not capture a username (entered in the front end) in
the pre-op bind plugin.
FreeIPA does not even call the pre-op plugin if it can not find a username,
entered in the front end, in the Directory Server.
What can I do to grab a username from the front end?
Thanks,
2 years, 11 months
Re: Cert expired for pki-tomcat and process would not start
by Rob Crittenden
Sayfiddin, Farhad wrote:
> Here is the output of getcert list
I think if you stop IPA, go back in time to when this server cert is
valid (it is the TLS cert for the CA server) and manually start dirsrv,
dogtag and krb5 then run certmonger resubmit -i 20170214143200
You want to be sure ntpd (or chronyc) isn't running to force time back
to now.
rob
>
> [root@sl1mmgplidm0002 ~]# getcert list
> Number of certificates and requests being tracked: 8.
> Request ID '20170214143155':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set
> certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> subject: CN=CA Audit,O=IPA.GEN.ZONE
> expires: 2020-12-01 18:52:55 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 '20170214143156':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set
> certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> subject: CN=OCSP Subsystem,O=IPA.GEN.ZONE
> expires: 2020-12-01 18:52:54 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 '20170214143157':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set
> certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> subject: CN=CA Subsystem,O=IPA.GEN.ZONE
> expires: 2020-12-01 18:53:15 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 '20170214143158':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set
> certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> subject: CN=Certificate Authority,O=IPA.GEN.ZONE
> expires: 2037-01-18 20:02:36 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 '20170214143159':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> subject: CN=IPA RA,O=IPA.GEN.ZONE
> expires: 2020-12-01 18:52:44 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 '20170214143200':
> status: CA_UNREACHABLE
> ca-error: Error 60 connecting to https://sl1mmgplidm0002.ipa.gen.zone:8443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with given CA certificates.
> stuck: no
> key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set
> certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> subject: CN=sl1mmgplidm0002.ipa.gen.zone,O=IPA.GEN.ZONE
> expires: 2019-01-08 20:16:52 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 '20170214143201':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IPA-GEN-ZONE',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-GEN-ZONE/pwdfile.txt'
> certificate: type=NSSDB,location='/etc/dirsrv/slapd-IPA-GEN-ZONE',nickname='Server-Cert',token='NSS Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> subject: CN=sl1mmgplidm0002.ipa.gen.zone,O=IPA.GEN.ZONE
> expires: 2020-12-23 03:40:21 UTC
> principal name: ldap/sl1mmgplidm0002.ipa.gen.zone(a)IPA.GEN.ZONE
> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IPA-GEN-ZONE
> track: yes
> auto-renew: yes
> Request ID '20170214143202':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> subject: CN=sl1mmgplidm0002.ipa.gen.zone,O=IPA.GEN.ZONE
> expires: 2020-12-23 03:40:31 UTC
> principal name: HTTP/sl1mmgplidm0002.ipa.gen.zone(a)IPA.GEN.ZONE
> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/libexec/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
>
> Already tried this solution with no luck:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__rcritten.wordpress.c...
>
> [root@sl1mmgplidm0002 ~]# certutil -d /etc/httpd/alias -L
>
> Certificate Nickname Trust Attributes
> SSL,S/MIME,JAR/XPI
>
> Server-Cert u,u,u
> ipaCert u,u,u
> IPA.GEN.ZONE IPA CA CT,C,C
>
> [root@sl1mmgplidm0002 ~]# certutil -d /etc/httpd/alias -M -n 'IPA.GEN.ZONE IPA CA' -t ',,'
> [root@sl1mmgplidm0002 ~]# certutil -d /etc/httpd/alias -M -n 'IPA.GEN.ZONE IPA CA' -t 'CT,C,C'
>
> Curl command still fails
>
> [root@sl1mmgplidm0002 ~]# SSL_DIR=/etc/httpd/alias/ curl -v -o /dev/null --cacert /etc/ipa/ca.crt https://`hostname`:8443/ca/agent/ca/profileReview
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* About to connect() to sl1mmgplidm0002.ipa.gen.zone port 8443 (#0)
> * Trying 172.20.0.36...
> * Connected to sl1mmgplidm0002.ipa.gen.zone (172.20.0.36) port 8443 (#0)
> * Initializing NSS with certpath: sql:/etc/httpd/alias/
> * CAfile: /etc/ipa/ca.crt
> CApath: none
> * Server certificate:
> * subject: CN=sl1mmgplidm0002.ipa.gen.zone,O=IPA.GEN.ZONE
> * start date: Jan 18 20:16:52 2017 GMT
> * expire date: Jan 08 20:16:52 2019 GMT
> * common name: sl1mmgplidm0002.ipa.gen.zone
> * issuer: CN=Certificate Authority,O=IPA.GEN.ZONE
> * NSS error -8181 (SEC_ERROR_EXPIRED_CERTIFICATE)
> * Peer's Certificate has expired.
> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
> * Closing connection 0
> curl: (60) Peer's Certificate has expired.
> More details here: http://curl.haxx.se/docs/sslcerts.html
>
> curl performs SSL certificate verification by default, using a "bundle"
> of Certificate Authority (CA) public keys (CA certs). If the default
> bundle file isn't adequate, you can specify an alternate file
> using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in
> the bundle, the certificate verification probably failed due to a
> problem with the certificate (it might be expired, or the name might
> not match the domain name in the URL).
> If you'd like to turn off curl's verification of the certificate, use
> the -k (or --insecure) option.
>
>
> -----Original Message-----
> From: Rob Crittenden <rcritten(a)redhat.com>
> Sent: Thursday, June 13, 2019 4:08 PM
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Cc: Sayfiddin, Farhad <fsayfiddin(a)tkcholdings.com>
> Subject: Re: [Freeipa-users] Cert expired for pki-tomcat and process would not start
>
> Sayfiddin, Farhad via FreeIPA-users wrote:
>> We have two replica servers sl1mmgplidm0001/2.
>>
>>
>>
>> sl1mmgplidm0001 is functioning as CRL master and has no issues.
>>
>>
>>
>> [root@sl1mmgplidm0001 ~]# ipa config-show | grep 'CA renewal master'
>>
>> IPA CA renewal master: sl1mmgplidm0001
>>
>> [root@sl1mmgplidm0001 ~]#
>>
>>
>>
>> [root@sl1mmgplidm0001 ~]# ipactl status
>>
>> Directory Service: RUNNING
>>
>> krb5kdc Service: RUNNING
>>
>> kadmin Service: RUNNING
>>
>> named Service: RUNNING
>>
>> ipa_memcached Service: RUNNING
>>
>> httpd Service: RUNNING
>>
>> ipa-custodia Service: RUNNING
>>
>> pki-tomcatd Service: RUNNING
>>
>> smb Service: RUNNING
>>
>> winbind Service: RUNNING
>>
>> ipa-otpd Service: RUNNING
>>
>> ipa-dnskeysyncd Service: RUNNING
>>
>> ipa: INFO: The ipactl command was successful
>>
>> [root@sl1mmgplidm0001 ~]#
>>
>>
>>
>> sl1mmgplidm0002 is having an issue where pki-tomcat process would not
>> start due to expired cert. It has CA_UNREACHABLE error
>>
>>
>>
>> [root@sl1mmgplidm0002 ~]# ipactl status
>>
>> Directory Service: RUNNING
>>
>> krb5kdc Service: RUNNING
>>
>> kadmin Service: RUNNING
>>
>> named Service: RUNNING
>>
>> ipa_memcached Service: RUNNING
>>
>> httpd Service: RUNNING
>>
>> ipa-custodia Service: RUNNING
>>
>> pki-tomcatd Service: STOPPED
>>
>> smb Service: RUNNING
>>
>> winbind Service: RUNNING
>>
>> ipa-otpd Service: RUNNING
>>
>> ipa-dnskeysyncd Service: RUNNING
>>
>> ipa: INFO: The ipactl command was successful
>>
>> [root@sl1mmgplidm0002 ~]#
>>
>>
>>
>> [root@sl1mmgplidm0002 ~]# getcert list | grep -A 10 20170214143200
>> Request ID '20170214143200':
>>
>> status: CA_UNREACHABLE
>>
>> ca-error: Error 60 connecting to
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sl1mmgplidm0002-3
>> A8443_ca_agent_ca_profileReview&d=DwIDAw&c=YQjZbjrpZrGDVqAPwjXLR6FCrpSyubErKtFCyGSfD8I&r=d-TYcZJsaxSN2fvTay_nSbRETC6Fq1LvfisROgToD30&m=vYnOqUeSIamQw5SC2J9Rs9eMlJ1Jd7WemUOfBlK_wz4&s=EvNOXdLcm_vL9kIJfZltxwLVIojayf1wau_ByrzA_m0&e= : Peer certificate cannot be authenticated with given CA certificates.
>>
>> stuck: no
>>
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>>
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
>> cert-pki-ca',token='NSS Certificate DB'
>>
>> CA: dogtag-ipa-renew-agent
>>
>> issuer: CN=Certificate Authority,O=IPA
>>
>> subject: CN=sl1mmgplidm0002,O=IPA
>>
>> expires: 2019-01-08 20:16:52 UTC
>>
>> key usage:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>
>> [root@sl1mmgplidm0002 ~]#
>>
>>
>>
>> Tried running renew_ca_cert command and "getcert resubmit -i" with no luck.
>
> Don't run ipa-cacert-manage renew. It renews only the root CA cert which won't help.
>
> We need to see the full output of getcert list to see what status all the certs are in.
>
> You might also try this:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__rcritten.wordpress.c...
>
> rob
>
2 years, 11 months
HA Client Question
by Christian Reiss
Hey folks,
I just recently began planning the deployment of FreeIPA and have
successfully made several test setups. Next step would be to integrate
this in our new datacenter; so we are starting there from scratch.
I understand HA on the server side. What boogles my head is HA on the
*client* side.
For example: Our pfsenses use a LDAP lookup against a single FQDN, and
the cert must be valid (against any provided CA). Exporting the CA from
freeIPA and importing that in pfsense is a cake.
But what do I point the clients towards? Let's say I have 4 FreeIPA servers:
- ipa01.auth.dc-01.company.com
- ipa02.auth.dc-01.company.com
- ipa03.auth.dc-01.company.com
- ipa04.auth.dc-01.company.com
Realm company.com, Kerberos COMPANY.COM. If I point the pfsense (I'll
stick to that as an example) against ipa01.auth.dc-01.company.com and
this server is offline, then no HA is given. DNS Delegation might yield
*any* of the four servers, including the one offline, so a 25% fault
chance in there.
Second question, same area: If I want my users to have one single url
for the FreeIPA webservice, like auth.company.com that follows the above
solution then the self-signed and generated certs do not have this as
altname.
So summed up:
- How can I make (ldap) clients access the current online server(s)?
- How can I provide access to the webinterace to the current online
server(s)?
(Or is this simply by the magic of dns zone delegation and pure faith
that always an online server will be hit?)
Thanks for any advice!
-Christian.
--
Christian Reiss - email(a)christian-reiss.de /"\ ASCII Ribbon
support(a)alpha-labs.net \ / Campaign
X against HTML
WEB alpha-labs.net / \ in eMails
GPG Retrieval https://gpg.christian-reiss.de
GPG ID ABCD43C5, 0x44E29126ABCD43C5
GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5
"It's better to reign in hell than to serve in heaven.",
John Milton, Paradise lost.
2 years, 11 months
Introducing ipa-healthcheck
by Rob Crittenden
I'd like to introduce a new tool for an IPA adminstrators tool kit we're
working on, currently in a beta state and shipping in Fedora 29+.
ipa-healthcheck is proactive tool for identifying current, potential and
future issues within an IPA installation.
It executes a series of checks in the areas of certificates, AD trust,
replication and the filesystem (and a few others). These checks can
return a success, warning or error. Any check executed will return a
value, the idea being if something with the check blows up and causes it
to not execute you'd otherwise not know and would have a false sense of
security.
A systemd timer is configured which will execute this on a nightly
basis, dumping the output in JSON format in /var/log/ipa/healthcheck/.
It can also be executed from the command-line as root and requires an
admin Kerberos ticket. From the command-line it is probably most useful
to use the --failures-only option in order to suppress the SUCCESS
messages: no news is good news in this case.
It currently only works with IPA 4.7.2+. Will we backport to 4.6? I
don't know yet.
I'd appreciate any feedback on whether it:
- is helpful
- works
- doesn't report false positives
- is usable: a lot of the output is what I think would be useful but we
won't know until applied in the real world
- does what you need. We can add more checks so if you have ideas please
let us know
Note that there are a few things we run that just produce output that
needs to be analyzed separately. DNA range checking is an example. It is
perfectly fine to not have a DNA range assigned on all masters but you'd
want to know if you had none defined on all masters.
thanks
rob
2 years, 11 months
Re: Cert expired for pki-tomcat and process would not start
by Rob Crittenden
Sayfiddin, Farhad via FreeIPA-users wrote:
> We have two replica servers sl1mmgplidm0001/2.
>
>
>
> sl1mmgplidm0001 is functioning as CRL master and has no issues.
>
>
>
> [root@sl1mmgplidm0001 ~]# ipa config-show | grep 'CA renewal master'
>
> IPA CA renewal master: sl1mmgplidm0001
>
> [root@sl1mmgplidm0001 ~]#
>
>
>
> [root@sl1mmgplidm0001 ~]# ipactl status
>
> Directory Service: RUNNING
>
> krb5kdc Service: RUNNING
>
> kadmin Service: RUNNING
>
> named Service: RUNNING
>
> ipa_memcached Service: RUNNING
>
> httpd Service: RUNNING
>
> ipa-custodia Service: RUNNING
>
> pki-tomcatd Service: RUNNING
>
> smb Service: RUNNING
>
> winbind Service: RUNNING
>
> ipa-otpd Service: RUNNING
>
> ipa-dnskeysyncd Service: RUNNING
>
> ipa: INFO: The ipactl command was successful
>
> [root@sl1mmgplidm0001 ~]#
>
>
>
> sl1mmgplidm0002 is having an issue where pki-tomcat process would not
> start due to expired cert. It has CA_UNREACHABLE error
>
>
>
> [root@sl1mmgplidm0002 ~]# ipactl status
>
> Directory Service: RUNNING
>
> krb5kdc Service: RUNNING
>
> kadmin Service: RUNNING
>
> named Service: RUNNING
>
> ipa_memcached Service: RUNNING
>
> httpd Service: RUNNING
>
> ipa-custodia Service: RUNNING
>
> pki-tomcatd Service: STOPPED
>
> smb Service: RUNNING
>
> winbind Service: RUNNING
>
> ipa-otpd Service: RUNNING
>
> ipa-dnskeysyncd Service: RUNNING
>
> ipa: INFO: The ipactl command was successful
>
> [root@sl1mmgplidm0002 ~]#
>
>
>
> [root@sl1mmgplidm0002 ~]# getcert list | grep -A 10 20170214143200
> Request ID '20170214143200':
>
> status: CA_UNREACHABLE
>
> ca-error: Error 60 connecting to
> https://sl1mmgplidm0002:8443/ca/agent/ca/profileReview: Peer certificate
> cannot be authenticated with given CA certificates.
>
> stuck: no
>
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca',token='NSS Certificate DB',pin set
>
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca',token='NSS Certificate DB'
>
> CA: dogtag-ipa-renew-agent
>
> issuer: CN=Certificate Authority,O=IPA
>
> subject: CN=sl1mmgplidm0002,O=IPA
>
> expires: 2019-01-08 20:16:52 UTC
>
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>
> [root@sl1mmgplidm0002 ~]#
>
>
>
> Tried running renew_ca_cert command and "getcert resubmit -i" with no luck.
Don't run ipa-cacert-manage renew. It renews only the root CA cert which
won't help.
We need to see the full output of getcert list to see what status all
the certs are in.
You might also try this:
https://rcritten.wordpress.com/2017/09/20/peer-certificate-cannot-be-auth...
rob
2 years, 11 months
Duplicate certificate tracking request
by Remco Kranenburg
Hi all,
We noticed that we have a duplicate tracking request for a certificate.
Is this normal, or can we remove one of them? We suspect that this
happened because we migrated our systems to another provider and we
made a mistake with FreeIPA.
The tracking requests as reported by getcert:
Request ID '20170801134610':
status: MONITORING
stuck: no
key pair storage:
type=FILE,location='/etc/ssl/private/ipa_host.key'
certificate: type=FILE,location='/etc/ssl/certs/ipa_host.crt'
CA: IPA
issuer: CN=Certificate Authority,O=EXAMPLE.COM
subject: CN=ipa.example.com,O=EXAMPLE.COM
expires: 2021-01-07 15:03:30 UTC
dns: ipa.example.com
principal name: host/ipa.example.com(a)EXAMPLE.COM
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20190107150328':
status: MONITORING
stuck: no
key pair storage:
type=FILE,location='/etc/ssl/private/ipa_host.key'
certificate: type=FILE,location='/etc/ssl/certs/ipa_host.crt'
CA: IPA
issuer: CN=Certificate Authority,O=EXAMPLE.COM
subject: CN=ipa.example.com,O=EXAMPLE.COM
expires: 2021-01-07 15:03:30 UTC
dns: ipa.example.com
principal name: host/ipa.example.com(a)EXAMPLE.COM
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
--
Remco Kranenburg
2 years, 11 months