[Announce] Security releases: FreeIPA 4.8.3, 4.7.4, and 4.6.7 released
by Alexander Bokovoy
Hello!
The FreeIPA team would like to announce FreeIPA security releases for
three release series: 4.8.3, 4.7.4, and 4.6.7 release!
Each series includes a security update release that contains fixes for two issues:
* CVE-2019-10195: Don't log passwords embedded in commands in calls using batch
A flaw was found in the way that FreeIPA's batch processing API logged
operations. This included passing user passwords in clear text on FreeIPA
masters. Batch processing of commands with passwords as arguments or options is
not performed by default in FreeIPA but is possible by third-party components.
An attacker having access to system logs on FreeIPA masters could use this flaw
to produce log file content with passwords exposed.
The issue was reported by Jamison Bennett from Cloudera
* CVE-2019-14867: Make sure to have storage space for tag
A flaw was found in the way the internal function ber_scanf() was used in some
components of the IPA server, which parsed kerberos key data. An
unauthenticated attacker who could trigger parsing of the krb principal key
could cause the IPA server to crash or in some conditions, cause arbitrary code
to be executed on the server hosting the IPA server.
The issue was reported by Todd Lipcon from Cloudera
== Upgrading ==
Upgrade instructions are available on [[Upgrade]] page.
== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users mailing
list (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...)
or #freeipa channel on Freenode.
== Detailed changelog since 4.6.6 ==
=== Alexander Bokovoy (1) ===
* Become FreeIPA 4.6.7
=== Rob Crittenden (1) ===
* CVE-2019-10195: Don't log passwords embedded in commands in calls using batch
=== Simo Sorce (1) ===
* CVE-2019-14867: Make sure to have storage space for tag
== Detailed changelog since 4.7.3 ==
=== Alexander Bokovoy (1) ===
* Become FreeIPA 4.7.4
=== Rob Crittenden (1) ===
* CVE-2019-10195: Don't log passwords embedded in commands in calls using batch
=== Simo Sorce (1) ===
* CVE-2019-14867: Make sure to have storage space for tag
== Detailed changelog since 4.8.2 ==
=== Alexander Bokovoy (1) ===
* Become FreeIPA 4.8.3
=== Rob Crittenden (1) ===
* CVE-2019-10195: Don't log passwords embedded in commands in calls using batch
=== Simo Sorce (1) ===
* CVE-2019-14867: Make sure to have storage space for tag
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
4 years, 4 months
"s2n exop request failed" errors.
by Jean Figarella
Hi, I have a customer that has both, RHEL 7 and RHEL 6 clients failing
logins with these "s2n exop request failed" errors.
>
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [sdap_process_result] (0x2000): Trace: sh[0x219b840], connected[1],
> ops[0x3209440], ldap[0x218dd00] (Sat Nov 16 12:40:21 2019) [sssd[be[
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Sat Nov
> 16 12:40:21 2019) [sssd[be[
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such
> object(32), (null). (Sat Nov 16 12:40:21 2019) [sssd[be[
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [sdap_op_destructor] (0x2000): Operation 27 finished (Sat Nov 16 12:40:21
> 2019) [sssd[be[
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Sat Nov 16
> 12:40:21 2019) [sssd[be[
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [sdap_id_op_done] (0x4000): releasing operation connection (Sat Nov 16
> 12:40:21 2019) [sssd[be[
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Sat
> Nov 16 12:40:21 2019) [sssd[be[
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [sdap_process_result] (0x2000): Trace: sh[0x219b840], connected[1],
> ops[(nil)], ldap[0x218dd00] (Sat Nov 16 12:40:21 2019) [sssd[be[
> (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]]
> [sdap_process_result] (0x2000): Trace: ldap_result found nothing! On RHEL
> 7, this was fixed by updating sssd to version > 1.13. Basically and update
> from RHEL 7.2 to 7.3 is all that is needed. However sssd-1.14 has not made
> it to rhel6 yet. Will this ever get fixed in RHEL 6? Thanks.
On RHEL 7, this was fixed by updating sssd to version > 1.13. Basically and
update from RHEL 7.2 to 7.3 is all that is needed. However sssd-1.14 has
not made it to rhel6 yet. Will this ever get fixed in RHEL 6? Thanks.
---
MR. JEAN FIGARELLA
PRINCIPAL CONSULTANT
Red Hat Consulting
North America Public Sector
jean(a)redhat.com
M: 5404293506
www.redhat.com
4 years, 4 months
freeipa communication to dogtag broken after certificates expired and ipa-cert-fix run
by Alexander Skobeltsin
Several days ago my freeipa (4.4) server was broken due to expiration of all certificates ( except ca of course). Because of in 4.4 was no such handy tool, as ipa-cert-fix, but lots of recovery methods, that I found in Google were using it, I decided to upgrade my broken freeipa to 4.5 ( by packages upgrade). Packages were installed succesfully, but automatic ipa-server-upgrade script after installation failed ( because of certificates, obviously). Then, I ran ipa-cert-fix and almost all freeipa certificates were succesfully resubmited and updated. Then, I tried to manually run ipa-server-upgrade, but it failed in the same place, as before updating certificates - on trying to communicate with dogtag. As well as I can't just start ipa (via "ipactl start"), but it works with "--force" option, and works well, except those part of ui, that shows certificates.
There is part of ipaupgrade.log, where upgrade fails:
2019-11-25T14:44:35Z DEBUG request GET https://ipa-vis.tis.rk:8443/ca/rest/account/login
2019-11-25T14:44:35Z DEBUG request body ''
2019-11-25T14:44:35Z DEBUG response status 401
2019-11-25T14:44:35Z DEBUG response headers Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 03:00:00 MSK
WWW-Authenticate: Basic realm="Certificate Authority"
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 951
Date: Mon, 25 Nov 2019 14:44:35 GMT
2019-11-25T14:44:35Z DEBUG response body '<html><head><title>Apache Tomcat/7.0.76 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 401 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>This request requires HTTP authentication.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.76</h3></body></html>'
2019-11-25T14:44:35Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2019-11-25T14:44:35Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 54, in run
server.upgrade()
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2146, in upgrade
upgrade_configuration()
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2018, in upgrade_configuration
ca_enable_ldap_profile_subsystem(ca)
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 406, in ca_enable_ldap_profile_subsystem
cainstance.migrate_profiles_to_ldap()
File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 2027, in migrate_profiles_to_ldap
_create_dogtag_profile(profile_id, profile_data, overwrite=False)
File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 2033, in _create_dogtag_profile
with api.Backend.ra_certprofile as profile_api:
File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1315, in __enter__
raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API'))
2019-11-25T14:44:35Z DEBUG The ipa-server-upgrade command failed, exception: RemoteRetrieveError: Failed to authenticate to CA REST API
After some searching, I found that such behaviour could be caused by incompatibility of newly generated ra-agent certificate in location "/var/lib/ipa/ra-agent.pem" and LDAP database in location "uid=ipara,ou=people,o=ipaca"(userCertificate,SeeAlso,description fields), and really, there was old certificates data there. I modified these 3 fields with corresponding new values from new certificate, including correct serial number in description. Here how it looks like now:
dn: uid=ipara,ou=people,o=ipaca
userCertificate: MIIDXD...NX7U3S
description: 2;16;CN=Certificate Authority,O=TIS.RK;CN=IPA RA,O=TIS.RK
pkidbuser LDAP entry contained old "CA Subsystem" also, so I modified it too with new "CA Subsystem" certificate data.
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate:: MIIDYj...+M7J8bmRc
description: 2;14;CN=Certificate Authority,O=TIS.RK;CN=CA Subsystem,O=TIS.RK
But none helped.
Here what I see in /var/log/pki/pki-tomcat/ca/debug, when trying to show certificate detail in freeipa's ui:
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet:service() uri = /ca/agent/ca/displayBySerial
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet::service() param name='xml' value='true'
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet::service() param name='serialNumber' value='20'
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: caDisplayBySerial start to service.
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: IP: 172.19.4.2
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: AuthMgrName: certUserDBAuthMgr
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: retrieving SSL certificate
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: certUID=CN=IPA RA,O=TIS.RK
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: started
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: Retrieving client certificate
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: Got client certificate
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn()
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 4
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 5
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: Authentication: client certificate found
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn()
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 5
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 6
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuthentication: cannot map certificate to any userServer Internal Error
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: SignedAuditLogger: event AUTH
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.java: renderTemplate
[25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.java: xml parameter detected, returning xml
Before I Updated IPA RA LDAP Entry, it showed "User not found" instead of "Server Internal Error".
And in dirsrv log I see such entries, when navigating to certificate detail page:
[25/Nov/2019:17:29:41.095869943 +0300] conn=40148 fd=206 slot=206 connection from 172.19.4.2 to 172.19.4.2
[25/Nov/2019:17:29:41.098585286 +0300] conn=40148 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO
[25/Nov/2019:17:29:41.103760424 +0300] conn=40148 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0005409737 dn="uid=admin,cn=users,cn=accounts,dc=tis,dc=rk"
[25/Nov/2019:17:29:41.105906742 +0300] conn=40148 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=tis,dc=rk" scope=0 filter="(objectClass=*)" attrs=ALL
[25/Nov/2019:17:29:41.106795977 +0300] conn=40148 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0000976075
[25/Nov/2019:17:29:41.108348488 +0300] conn=40148 op=2 SRCH base="cn=masters,cn=ipa,cn=etc,dc=tis,dc=rk" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL
[25/Nov/2019:17:29:41.108921046 +0300] conn=40148 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000658341
[25/Nov/2019:17:29:41.135945117 +0300] conn=27 op=13 SRCH base="ou=People,o=ipaca" scope=2 filter="(description=2;16;CN=Certificate Authority,O=TIS.RK;CN=IPA RA,O=TIS.RK)" attrs=ALL
[25/Nov/2019:17:29:41.136203891 +0300] conn=27 op=13 RESULT err=0 tag=101 nentries=1 etime=0.0000356148
[25/Nov/2019:17:29:41.142786310 +0300] conn=40148 op=3 UNBIND
[25/Nov/2019:17:29:41.142807994 +0300] conn=40148 op=3 fd=206 closed - U1
Now I am stuck at this point. I don't understand, what is wrong with dogtag, is it LDAP entry trouble or dogtags itself.
There are some errors in "getcert list" output,
4 years, 4 months
OTP implementation
by mizuki
Hi all,
We started looking into OTP features provided by IPA in our facility. In
our environment, majority of our machines are located in the private
network, users access them via external-facing Gateways. We want to enforce
MFA on our gateway and allow users to have freedom SSH-ing into any
internal nodes using their regular passwords (or keys). Then add HBAC rules
for certain hosts/services who require MFA authentications using OTP (for
example, protected web resource access. NX etc) In order to achieve that,
it seems to me we need turn on both 'password' and 'otp' for individual
users or globally. This will then trigger 'password' for SSH and 'otp' auth
for WebApps/NX and so on.
However when I looked at the online document @
https://www.freeipa.org/page/V4/OTP#Implementation , it stated "*Mixing the
"password" and "otp" user auth types should not be used*", I wonder why
"mixing" is not recommended, and what is the downside if we implement this
way(in order to achieve what we're trying to do), or any other better
strategies in this case?
Can some advice? Thank you in advance!
Mizuki
4 years, 4 months
FreeIPA certificates to create a keystore
by Hernán Fernández
Hello,
I have a FreeIPA server and about 7 nodes, each node has a certificate and
a key.
I got those host certificates with:
ipa-getcert request -v -f /etc/security/certificates/host.crt -k
/etc/security/certificates/host.key
I can see the CA certificate it's located at /etc/ipa/ca.crt. Where is the
CAKey file?. I need to create a Keystore for the host.
Thanks
--
Hernán Fernández
4 years, 4 months
Certificate Renewal less than 28days
by Christof Schulze
Reading a lot I learned that certificates should be renewed
automatically 28 before expiring.
But some of Certificates are now on less than 10 days.
This is on the CA renewal master:
Request ID '20181008075404':
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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY
subject: CN=OCSP
Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY
expires: 2019-11-30 11:12:26 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 '20181008075405':
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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY
subject: CN=CA
Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY
expires: 2019-11-30 11:11:38 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 '20181008075407':
status: MONITORING
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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY
subject: CN=IPA
RA,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY
expires: 2019-11-30 11:10:54 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
Is there a way to get them renewed manually?
--
Christof Schulze
Email: christof.schulze(a)fau.de
4 years, 4 months
ipa-getkeytab -r for user keytabs
by Dmitry Perets
Hi,
Is it possible to retrieve an existing user keytab, without resetting the key?
I see there is "ipa-getkeytab -r", but it doesn't seem to work for me, at least not for user principals:
$ kinit admin
<password>
$ ipa-getkeytab -p auto -r -k new.auto.keytab
Failed to load translations
Failed to parse result: Insufficient access rights
Failed to get keytab
Should I add some permissions to the user "admin"...?
---
Regards,
Dmitry Perets
4 years, 4 months
Re: Issues with certificates: X509: KEY_VALUES_MISMATCH
by Dmitri Moudraninets
Hi Rob,
Some good news. I did the same with the secondary server. Now on secondary
server I can navigate through GUI with out any errors
(authentication->certificates->certificates). But on the first server
Subjects are missing and all certificates are grayed-out except one.
Another good thing - on both servers I can go to identity->users, then I
click on a user who has a personal certificate. And I can see the
certificate data via GUI.
Also if I run ipa-server-upgrade it fails on a first server with he
following message:
2019-11-25T13:34:26Z DEBUG The ipa-server-upgrade command failed,
exception: NetworkError: cannot connect to '
https://freeipa.corp.mydomain.de:8443/ca/rest/account/login': [SSL:
TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:618)
2019-11-25T13:34:26Z ERROR Unexpected error - see /var/log/ipaupgrade.log
for details:
NetworkError: cannot connect to '
https://freeipa.corp.mydomain.de:8443/ca/rest/account/login': [SSL:
TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:618)
2019-11-25T13:34:26Z ERROR The ipa-server-upgrade command failed. See
/var/log/ipaupgrade.log for more information
If I run ipa-cert-show 1 on a first server I see this:
[root@freeipa ipa]# ipa cert-show 1
ipa: DEBUG: importing all plugin modules in
ipaclient.remote_plugins.schema$5131ac65...
ipa: DEBUG: importing plugin module
ipaclient.remote_plugins.schema$5131ac65.plugins
ipa: DEBUG: importing all plugin modules in ipaclient.plugins...
ipa: DEBUG: importing plugin module ipaclient.plugins.automember
ipa: DEBUG: importing plugin module ipaclient.plugins.automount
ipa: DEBUG: importing plugin module ipaclient.plugins.ca
ipa: DEBUG: importing plugin module ipaclient.plugins.cert
ipa: DEBUG: importing plugin module ipaclient.plugins.certmap
ipa: DEBUG: importing plugin module ipaclient.plugins.certprofile
ipa: DEBUG: importing plugin module ipaclient.plugins.csrgen
ipa: DEBUG: importing plugin module ipaclient.plugins.dns
ipa: DEBUG: importing plugin module ipaclient.plugins.hbacrule
ipa: DEBUG: importing plugin module ipaclient.plugins.hbactest
ipa: DEBUG: importing plugin module ipaclient.plugins.host
ipa: DEBUG: importing plugin module ipaclient.plugins.idrange
ipa: DEBUG: importing plugin module ipaclient.plugins.internal
ipa: DEBUG: importing plugin module ipaclient.plugins.location
ipa: DEBUG: importing plugin module ipaclient.plugins.migration
ipa: DEBUG: importing plugin module ipaclient.plugins.misc
ipa: DEBUG: importing plugin module ipaclient.plugins.otptoken
ipa: DEBUG: importing plugin module ipaclient.plugins.otptoken_yubikey
ipa: DEBUG: importing plugin module ipaclient.plugins.passwd
ipa: DEBUG: importing plugin module ipaclient.plugins.permission
ipa: DEBUG: importing plugin module ipaclient.plugins.rpcclient
ipa: DEBUG: importing plugin module ipaclient.plugins.server
ipa: DEBUG: importing plugin module ipaclient.plugins.service
ipa: DEBUG: importing plugin module ipaclient.plugins.sudorule
ipa: DEBUG: importing plugin module ipaclient.plugins.topology
ipa: DEBUG: importing plugin module ipaclient.plugins.trust
ipa: DEBUG: importing plugin module ipaclient.plugins.user
ipa: DEBUG: importing plugin module ipaclient.plugins.vault
ipa: DEBUG: found session_cookie in persistent storage for principal '
admin(a)CORP.mydomain.DE', cookie:
'ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d'
ipa: DEBUG: setting session_cookie into context
'ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;'
ipa: INFO: trying https://freeipa.corp.mydomain.de/ipa/session/json
ipa: DEBUG: New HTTP connection (freeipa.corp.mydomain.de)
ipa: DEBUG: received Set-Cookie (<type
'list'>)'['ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;path=/ipa;httponly;secure;']'
ipa: DEBUG: storing cookie
'ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;'
for principal admin(a)CORP.mydomain.DE
ipa: DEBUG: Created connection context.rpcclient_140099072449040
ipa: DEBUG: raw: cert_show(u'1', version=u'2.230')
ipa: DEBUG: cert_show(u'1', version=u'2.230')
ipa: INFO: [try 1]: Forwarding 'cert_show/1' to json server '
https://freeipa.corp.mydomain.de/ipa/session/json'
ipa: DEBUG: HTTP connection keep-alive (freeipa.corp.mydomain.de)
ipa: DEBUG: received Set-Cookie (<type
'list'>)'['ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;path=/ipa;httponly;secure;']'
ipa: DEBUG: storing cookie
'ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;'
for principal admin(a)CORP.mydomain.DE
ipa: DEBUG: Destroyed connection context.rpcclient_140099072449040
ipa: ERROR: cannot connect to '
https://freeipa.corp.mydomain.de:443/ca/agent/ca/displayBySerial': [Errno
13] Permission denied
on a second server it prints a certificate:
[root@freeipa-02 ~]# ipa cert-show 1
Issuing CA: ipa
Certificate: MIIDozCC.....uU=
Subject: CN=Certificate Authority,O=CORP.MYDOMAIN.DE
Issuer: CN=Certificate Authority,O=CORP.MYDOMAIN.DE
Not Before: Tue Dec 05 15:31:39 2017 UTC
Not After: Sat Dec 05 15:31:39 2037 UTC
Serial number: 1
Serial number (hex): 0x1
Revoked: False
пн, 25 нояб. 2019 г. в 14:07, Robert Crittenden <rcritten(a)redhat.com>:
> I am out of the office until December 2, 2019.
>
>
--
With best regards/Mit freundlichen Grüßen
Moudraninets Dmitry, RHCSA
http://www.linkedin.com/in/moudraninets
http://www.xing.com/profile/Dmitry_Mudraninets
4 years, 4 months
Issues with certificates: X509: KEY_VALUES_MISMATCH
by Dmitri Moudraninets
Hi All,
I have a werid issue with FreeIPA. I can't do anything with certificates. I
also can't upgrade FreeIPA. If I run ipa-server-update I receive this:
Unexpected error - see /var/log/ipaupgrade.log for details:
NetworkError: cannot connect to '
https://freeipa.corp.mydomain.com:8443/ca/rest/account/login': [X509:
KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:2593)
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more
information
If I try to vew certificates via web interface I see this error message:
IPA Error 907: NetworkError
cannot connect to '
https://freeipa.corp.mydomain.com:443/ca/agent/ca/displayBySerial': [X509:
KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:2593)
Below is the list of my certificates:
# getcert list | egrep '^Request|status:|subject:'
Request ID '20171205153653':
status: MONITORING
subject: CN=freeipa.corp.mydomain.com,O=CORP.MYDOMAIN.COM
Request ID '20180912151607':
status: CA_UNREACHABLE
subject: CN=CA Audit,O=CORP.MYDOMAIN.COM
Request ID '20180912151608':
status: CA_UNREACHABLE
subject: CN=OCSP Subsystem,O=CORP.MYDOMAIN.COM
Request ID '20180912151609':
status: CA_UNREACHABLE
subject: CN=CA Subsystem,O=CORP.MYDOMAIN.COM
Request ID '20180912151610':
status: MONITORING
subject: CN=Certificate Authority,O=CORP.MYDOMAIN.COM
Request ID '20180912151611':
status: MONITORING
subject: CN=user,O=CORP.MYDOMAIN.COM
Request ID '20180912151612':
status: CA_UNREACHABLE
subject: CN=freeipa.corp.mydomain.com,O=CORP.MYDOMAIN.COM
Request ID '20180912151613':
status: MONITORING
subject: CN=freeipa.corp.mydomain.com,O=CORP.MYDOMAIN.COM
Request ID '20180912151615':
status: MONITORING
subject: CN=freeipa.corp.mydomain.com,O=CORP.MYDOMAIN.COM
Request ID '20190212162113':
status: MONITORING
subject: CN=mail.corp.mydomain.com,O=CORP.MYDOMAIN.COM
Request ID '20191017155747':
status: MONITORING
subject: CN=analytics-stage.corp.mydomain.com,O=CORP.MYDOMAIN.COM
Request ID '20191026094947':
status: MONITORING
subject: CN=nas.corp.mydomain.com,O=CORP.MYDOMAIN.COM
Request ID '20191026102844':
status: MONITORING
subject: CN=pe.corp.mydomain.com,O=CORP.MYDOMAIN.COM
Request ID '20191027134809':
status: CA_UNREACHABLE
subject:
Request ID '20191027135053':
status: CA_REJECTED
subject:
Request ID '20191027135738':
status: CA_UNREACHABLE
subject:
I tried to set time on the server back and I tried to restart certmonger -
but result is always the same - SSL error KEY_VALUES_MISMATCH. FreeIPA,
version: 4.6.4
How to solve this issue?
--
WBR
Dmitry
4 years, 4 months
Certificates renewal - for certs issued to services like HTTP
by John Stokes
Hi all,
I have a question regarding renewal of certificates issued to http services.
I read somewhere that these certificates are automatically renewed but could not find any more details.
My deployment is a standard one and I'm using the caIPAserviceCert profile.
Can anyone shed some light on the process of renewals of certificates issued to servers? If the renewal is automatic where will the new cert (I suppose key file will be the same) be stored and when is the renewal being done (how many days before it expires)?
4 years, 4 months