Resilience when accessing CA
by Dmitry Perets
Hi,
In several scenarios when CA must be accessed, I face issues with the algorithm to select IPA server running CA.
Wanted to check if there is an easy solution in place that I am missing...
For example, if I run "ipa vault-retrieve" on IPA server that doesn't run CA/KRA, it will forward the request to another IPA server.
But how will it choose one?
From my tests, looks like the algorithm is:
- If "ca_host" is defined in /etc/ipa/default.conf, use that IPA server
- If it's not defined, fallback to LDAP lookup - query "cn=masters,cn=ipa,cn=etc,<base-dn>" for servers that have KRA and... choose the first result.
So the problem is that neither of these two methods is redundant. If the chosen IPA server is down, it just fails, it doesn't try the others.
Is there any solution for this?
I thought it was specific to Vault access, but I discovered the same thing when I simply do "ipa host-disable" for some host.
Seems that also in this case there is a need to access CA, so the IPA server applies the same algorithm as above - so it looks.
And again, no redundancy. If it cannot reach the chosen IPA server, it won't try any other.
Can you confirm that the algorighm is as described above?
Or am I missing anything?
Thanks.
---
Regards,
Dmitry Perets
4 years, 6 months
ipausers unable to sudo
by Albert Szostkiewicz
Hi!
I've reinstalled ipa-client on a workstation and for some reason now ipa users are not part of sudoers
File `/etc/nsswitch.conf` contains `sudoers: files sss`
File '/etc/sssd/sssd.conf' contains `[sssd] services = nss, pam, ssh, sudo, autofs`
There is no 'sudo_provider' within sssd.conf
I've tried to go through provided troubleshooting guide but even seeing discrepancies, I am not sure what should i do about it.
Here are snippets of what troubleshooting was suggesting to look for:
[sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 default options for [myipauser@home.mydomain.com(a)home.mydomain.com]
[sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [myipauser@home.mydomain.com(a)home.mydomain.com]
[sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=myipauser@home.mydomain.com)(sudoUser=#1907400001)(sudoUser=%editors@home.mydomain.com)(sudoUser=%trust\20admins@home.mydomain.com)(sudoUser=%admins@home.mydomain.com)(sudoUser=%ipausers@home.mydomain.com)(sudoUser=%mymaingroup@home.mydomain.com)(sudoUser=%gogs_users@home.mydomain.com)(sudoUser=%admins(a)home.mydomain.com))))]
# record 28
dn: name=su,cn=hbac_services,cn=custom,cn=home.mydomain.com,cn=sysdb
# record 29
dn: name=myipauser(a)home.mydomain.com,cn=users,cn=home.mydomain.com,cn=sysdb
[sdap_search_bases_ex_done] (0x0400): Receiving data from base [cn=sudo,dc=home,dc=mydomain,dc=com]
[sssd[be[home.mydomain.com]]] [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules
[sysdb_sudo_store_rule] (0x0400): Adding sudo rule All
[sssd[be[home.mydomain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipasudocmdgrp)(entryUSN>=24976))][cn=sudo,dc=home,dc=mydomain,dc=com].
I do not have '[sdap_sudo_refresh_load_done]' within sssd_$domain.log
> ldapsearch -x -H ldap://ipaserver.home.mydomain.com -b dc=ipaserver,dc=home,dc=mydomain,dc=com '$filter'
# extended LDIF
#
# LDAPv3
# base <dc=ipaserver,dc=home,dc=mydomain,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: $filter
#
# search result
search: 2
result: 0 Success
# numResponses: 1
> ldapsearch -x -D "cn=Directory Manager" -w "$password" -H ldap://ipaserver.home.mydomain.com -b dc=ipaserver,dc=home,dc=mydomain,dc=com '$filter'
ldap_bind: Server is unwilling to perform (53)
additional info: Unauthenticated binds are not allowed
> ldapsearch -Y GSSAPI -H ldap://ipaserver.home.mydomain.com -b dc=ipaserver,dc=home,dc=mydomain,dc=com '$filter'
SASL/GSSAPI authentication started
SASL username: host/myworkstation.home.mydomain.com(a)HOME.MYDOMAIN.COM
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ipaserver,dc=home,dc=mydomain,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: $filter
#
# search result
search: 4
result: 0 Success
# numResponses: 1
sudo[411] -> sudo_parseln_v2 @ ./parseln.c:59
sudo[411] <- sudo_parseln_v2 @ ./parseln.c:129 := 0
sudo[411] <- sudo_sss_open @ ./sssd.c:628 := 0
sudo[411] Looking for cn=default
sudo[411] Received 0 rule(s)
Any help would be appreciated!
Cheers!
4 years, 6 months
Issues with config between FreeIPA and Dell EMC Unity NAS server
by Kevin Vasko
I’m trying to integrate the “NAS Server” on our Dell EMC Unity with our FreeIPA server so we can secure our NFS shares. Our FreeIPA server is run of the mill setup. We don’t have any special configuration.
The Dell EMC Box NAS configuration settings is asking for the following.
Realm:
KDC Servers:
Port:
Base DN:
Custom Principal:
Custom Principal password:
Keytab
You can get a better visual from these screenshots. https://imgur.com/a/H6pWemL
Info about the environment (I switched example.com from our regular domain but it’s a direct replacement).
ny.example.com is my main domain/realm (e.g. NY.EXAMPLE.COM). My other domain is la.example.com. My KDC (IPA servers) are ipa.ny.example.com and ipa.la.example.com, they are replicas. The Dell EMC Unity NAS server I’m setting up will be nfssrv.la.example.com.
So this is what I did. In FreeIPA I create a new host manually through the gui.
Principle alias:
nfssrv.la.example.com(a)NY.EXAMPLE.COM
I then created a new service with that host through the gui
nfs/nfssrv.la.example.com(a)NY.EXAMPLE.COM
I then went into the freeIPA server and generated a keytab
"ipa-getkeytab -s ipa.ny.example.com -p nfs/nfssrv.la.example.com(a)NY.EXAMPLE.COM -k /tmp/nfssrv.keytab -P <entered passwd>"
The principal in the ipa-getkeytab command and the password I supplied to the ipa-getkeytab command is what I supplied in the Dell EMC Unity dialogs.
However, when I do all of this, I keep getting errors in the Dell EMC Unity log stating
“In the NAS server nfssrv.la.example.com, ONE LDAP server for Domain ny.example.com goes back from failure.”
“LDAP client settings on NAS server nfssrv.la.example.com are not valid within domain ny.example.com”.
So the questions I have are.
1) Am I generating the keytab appropriately?
2) Am I supplying the correct information to the “Specifiy Custom principal” “Principal” fields with the principal of the actual server?
3) The last thing I am unsure about is the “Retrieve Current Schema”. This schema was automatically generated. It states is for the Fedora Directory Service so I assumed that’s was correct since I’m using CentOS with FreeIPA. I haven’t changed anything in the scheme (at least that i’m aware of). Any way to validate this?
If anyone can provide any advice/suggestions I would greatly appreciate it.
The following is the “Current Schema” listed in the LDAP section.
# -----------------------------------------------------------------------------
# This template was automatically generated by the EMC Nas server
# - Adjustments could be required to fit your specific LDAP configuration.
# - The following setup fits the Fedora Directory service schema.
# Containers
nss_base_passwd ou=people,dc=ny,dc=example,dc=com
nss_base_group ou=group,dc=ny,dc=example,dc=com
nss_base_hosts ou=hosts, dc=ny,dc=example,dc=com
nss_base_netgroup ou=netgroup,dc=ny,dc=example,dc=com
# - The parameter fast_search allows fast search encoding to boost performances with big LDAP repositories.
# The parameter is set to 1 by default on this configuration,# Some issue could occurs on Microsoft Active Directory server.
# If you encounter some issue on LDAP lookup, set the value of the parameter to 0
fast_search 1
-Kevin
4 years, 6 months
Re: Cert Issue
by Rob Crittenden
Randy Morgan wrote:
> On 9/9/2019 11:31 AM, Rob Crittenden wrote:
>> Randy Morgan via FreeIPA-users wrote:
>>> We have been working to solve an expired certificate issue in IPA.
>>> There is an open ticket in Red Hat supportCASE 02438518. We have tried
>>> many things but so far have had no luck getting the certs to update.
>>> Currently the system is running RHEL 8.0 and IPA 4.7.1.
>>>
>>> pki-server cert-fix -n 'subsystemCert cert-pki-ca' -d
>>> /var/lib/pki/pki-tomcat/alias/ -C /root/passwd -vvv
>>> INFO: Loading instance: pki-tomcat
>>> INFO: Loading instance registry:
>>> /etc/sysconfig/pki/tomcat/pki-tomcat/pki-tomcat
>>> INFO: Loading password config: /etc/pki/pki-tomcat/password.conf
>>> INFO: Loading subsystem: ca
>>> INFO: Loading subsystem config: /var/lib/pki/pki-tomcat/ca/conf/CS.cfg
>>> INFO: Getting signing cert info for ca from CS.cfg
>>> INFO: Getting signing cert info for ca from NSS database
>>> INFO: Getting ocsp_signing cert info for ca from CS.cfg
>>> INFO: Getting ocsp_signing cert info for ca from NSS database
>>> INFO: Getting sslserver cert info for ca from CS.cfg
>>> INFO: Getting sslserver cert info for ca from NSS database
>>> INFO: Getting subsystem cert info for ca from CS.cfg
>>> INFO: Getting subsystem cert info for ca from NSS database
>>> INFO: Getting audit_signing cert info for ca from CS.cfg
>>> INFO: Getting audit_signing cert info for ca from NSS database
>>> INFO: Fixing the following certs: ['ca_ocsp_signing', 'sslserver',
>>> 'subsystem', 'ca_audit_signing']
>>> INFO: Stopping the instance to proceed with system cert renewal
>>> INFO: Selftests disabled for subsystems: ca
>>> INFO: Getting sslserver cert info for ca from CS.cfg
>>> INFO: Getting sslserver cert info for ca from NSS database
>>> INFO: Trying to create a new temp cert for sslserver.
>>> INFO: Generate temp SSL certificate
>>> INFO: Getting sslserver cert info for ca from CS.cfg
>>> INFO: Getting sslserver cert info for ca from NSS database
>>> INFO: CSR for sslserver has been written to
>>> /tmp/tmpg_738l5a/sslserver.csr
>>> INFO: Getting signing cert info for ca from CS.cfg
>>> INFO: Getting signing cert info for ca from NSS database
>>> INFO: CA cert written to /tmp/tmpg_738l5a/ca_certificate.crt
>>> INFO: AKI: 0x1D0F356A3E7A6968A231723231EB22DA5A01F542
>>> INFO: Temp cert for sslserver is available at
>>> /etc/pki/pki-tomcat/certs/sslserver.crt.
>>> INFO: Getting sslserver cert info for ca from CS.cfg
>>> INFO: Getting sslserver cert info for ca from NSS database
>>> INFO: Getting sslserver cert info for ca from CS.cfg
>>> INFO: Getting sslserver cert info for ca from NSS database
>>> INFO: Updating CS.cfg with the new certificate
>>> INFO: Getting ocsp_signing cert info for ca from CS.cfg
>>> INFO: Getting ocsp_signing cert info for ca from NSS database
>>> INFO: Trying to setup a secure connection to CA subsystem.
>>> INFO: Secure connection with CA is established.
>>> INFO: Placing cert creation request for serial: 49
>>> Traceback (most recent call last):
>>> File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py",
>>> line 600, in urlopen
>>> chunked=chunked)
>>> File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py",
>>> line 343, in _make_request
>>> self._validate_conn(conn)
>>> File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py",
>>> line 849, in _validate_conn
>>> conn.connect()
>>> File "/usr/lib/python3.6/site-packages/urllib3/connection.py",
>>> line 356, in connect
>>> ssl_context=context)
>>> File "/usr/lib/python3.6/site-packages/urllib3/util/ssl_.py", line
>>> 350, in ssl_wrap_socket
>>> context.load_cert_chain(certfile, keyfile)
>>> ssl.SSLError: [X509: KEY_VALUES_MISMATCH] key values mismatch
>>> (_ssl.c:3550)
>>>
>>> During handling of the above exception, another exception occurred:
>>>
>>> Traceback (most recent call last):
>>> File "/usr/lib/python3.6/site-packages/requests/adapters.py", line
>>> 449, in send
>>> timeout=timeout
>>> File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py",
>>> line 638, in urlopen
>>> _stacktrace=sys.exc_info()[2])
>>> File "/usr/lib/python3.6/site-packages/urllib3/util/retry.py",
>>> line 398, in increment
>>> raise MaxRetryError(_pool, url, error or ResponseError(cause))
>>> urllib3.exceptions.MaxRetryError:
>>> HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries
>>> exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal
>>> (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH]
>>> key values mismatch (_ssl.c:3550)'),))
>>>
>>> During handling of the above exception, another exception occurred:
>>>
>>> Traceback (most recent call last):
>>> File "/usr/lib/python3.6/site-packages/pki/server/pkiserver.py",
>>> line 119, in <module>
>>> cli.execute(sys.argv)
>>> File "/usr/lib/python3.6/site-packages/pki/server/pkiserver.py",
>>> line 111, in execute
>>> super(PKIServerCLI, self).execute(args)
>>> File "/usr/lib/python3.6/site-packages/pki/cli/__init__.py", line
>>> 204, in execute
>>> module.execute(module_args)
>>> File "/usr/lib/python3.6/site-packages/pki/cli/__init__.py", line
>>> 204, in execute
>>> module.execute(module_args)
>>> File "/usr/lib/python3.6/site-packages/pki/server/cli/cert.py",
>>> line 1154, in execute
>>> renew=True)
>>> File "/usr/lib/python3.6/site-packages/pki/server/__init__.py",
>>> line 1709, in cert_create
>>> PKIServer.renew_certificate(connection, new_cert_file, serial)
>>> File "/usr/lib/python3.6/site-packages/pki/server/__init__.py",
>>> line 202, in renew_certificate
>>> ret = cert_client.enroll_cert(inputs=inputs,
>>> profile_id='caManualRenewal')
>>> File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442,
>>> in handler
>>> return fn_call(inst, *args, **kwargs)
>>> File "/usr/lib/python3.6/site-packages/pki/cert.py", line 1011, in
>>> enroll_cert
>>> enroll_request = self.create_enrollment_request(profile_id, inputs)
>>> File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442,
>>> in handler
>>> return fn_call(inst, *args, **kwargs)
>>> File "/usr/lib/python3.6/site-packages/pki/cert.py", line 962, in
>>> create_enrollment_request
>>> enrollment_template = self.get_enrollment_template(profile_id)
>>> File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442,
>>> in handler
>>> return fn_call(inst, *args, **kwargs)
>>> File "/usr/lib/python3.6/site-packages/pki/cert.py", line 942, in
>>> get_enrollment_template
>>> r = self.connection.get(url, self.headers)
>>> File "/usr/lib/python3.6/site-packages/pki/client.py", line 46, in
>>> wrapper
>>> return func(self, *args, **kwargs)
>>> File "/usr/lib/python3.6/site-packages/pki/client.py", line 160,
>>> in get
>>> timeout=timeout,
>>> File "/usr/lib/python3.6/site-packages/requests/sessions.py", line
>>> 537, in get
>>> return self.request('GET', url, **kwargs)
>>> File "/usr/lib/python3.6/site-packages/requests/sessions.py", line
>>> 524, in request
>>> resp = self.send(prep, **send_kwargs)
>>> File "/usr/lib/python3.6/site-packages/requests/sessions.py", line
>>> 637, in send
>>> r = adapter.send(request, **kwargs)
>>> File "/usr/lib/python3.6/site-packages/requests/adapters.py", line
>>> 514, in send
>>> raise SSLError(e, request=request)
>>> requests.exceptions.SSLError:
>>> HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries
>>> exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal
>>> (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH]
>>> key values mismatch (_ssl.c:3550)'),))
>>> ERROR: HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max
>>> retries exceeded with url:
>>> /ca/rest/certrequests/profiles/caManualRenewal (Caused by
>>> SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] key values
>>> mismatch (_ssl.c:3550)'),))
>>>
>>> [root@ipa2 ~]# echo "--Certificate:" && openssl x509 -noout -modulus -in
>>> /var/lib/ipa/ra-agent.pem && echo "--Key:" && openssl rsa -noout
>>> -modulus -in /var/lib/ipa/ra-agent.key
>>> --Certificate:
>>> Modulus=CBA68178847F53CC0D4A45871FEA7CCFD879D6423923DF75E557011E4C458BD5207ACBB4EAFC7A460C050878621E22406E7661105F7D8E7AF448AA1F0988C908F3173B77D87581BE7006ED09F76F0D4D736050088E986133DE851A0FB93A101AA77921CC24063A94E5076FD74D4D81139E7A2AAC61B86D07D424158CE56913ABB08C1CDBDAE35CE2D7BCEB9EF9D5A909FFF502A02E1E847DC44E8672A8889A65A721DC78FE70C24D9E12BB4E88D7AD0A49948E2BF40A22431731872ADFC3B81E368C655EB9B00DC37D04526EE2917445D2FAEBCF116821486FF088E500F12128A8D90309E8ED275CDD48E77BDE0E3358A6A81BD9DD2AD5AC6F68315C96FC50E9
>>>
>>> --Key:
>>> Modulus=CBA68178847F53CC0D4A45871FEA7CCFD879D6423923DF75E557011E4C458BD5207ACBB4EAFC7A460C050878621E22406E7661105F7D8E7AF448AA1F0988C908F3173B77D87581BE7006ED09F76F0D4D736050088E986133DE851A0FB93A101AA77921CC24063A94E5076FD74D4D81139E7A2AAC61B86D07D424158CE56913ABB08C1CDBDAE35CE2D7BCEB9EF9D5A909FFF502A02E1E847DC44E8672A8889A65A721DC78FE70C24D9E12BB4E88D7AD0A49948E2BF40A22431731872ADFC3B81E368C655EB9B00DC37D04526EE2917445D2FAEBCF116821486FF088E500F12128A8D90309E8ED275CDD48E77BDE0E3358A6A81BD9DD2AD5AC6F68315C96FC50E9
>>>
>>> [root@ipa2 ~]# openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key
>>> | openssl md5
>>> (stdin)= 0915781edbe620c5791cda50f310c538
>>> [root@ipa2 ~]# openssl x509 -noout -modulus -in
>>> /var/lib/ipa/ra-agent.pem | openssl md5
>>> (stdin)= 0915781edbe620c5791cda50f310c538
>>>
>>> Looking at the cert and the key, they are a match and modulus also
>>> matches. What I can't figure out is why I am seeing this error if the
>>> key and cert match. Is it possible to have a timestamp issue, or is
>>> there some other reason that I can't find. Any help would be greatly
>>> appreciated.
>> I'm not familiar with this command but based on the options you are
>> passing you compared the wrong cert. You compared the RA agent cert and
>> you asked to renew the subsystem cert.
>>
>> You might want to see what cert owns serial number 49.
>>
>> rob
>
>
> The reason these are the two compared is that there are no other keys on
> the server. Looking through the documentation seems to indicate that
> all certs are generated from this key pair. Is that not correct, and if
> it is not correct then where are the keys located for the other certs, I
> have been unable to locate them anywhere on the server.
The certs and keys are stored in the NSS database in
/etc/pki/pki-tomcat/alias/
rob
4 years, 6 months
Cert Issue
by Randy Morgan
We have been working to solve an expired certificate issue in IPA.
There is an open ticket in Red Hat supportCASE 02438518. We have tried
many things but so far have had no luck getting the certs to update.
Currently the system is running RHEL 8.0 and IPA 4.7.1.
pki-server cert-fix -n 'subsystemCert cert-pki-ca' -d /var/lib/pki/pki-tomcat/alias/ -C /root/passwd -vvv
INFO: Loading instance: pki-tomcat
INFO: Loading instance registry: /etc/sysconfig/pki/tomcat/pki-tomcat/pki-tomcat
INFO: Loading password config: /etc/pki/pki-tomcat/password.conf
INFO: Loading subsystem: ca
INFO: Loading subsystem config: /var/lib/pki/pki-tomcat/ca/conf/CS.cfg
INFO: Getting signing cert info for ca from CS.cfg
INFO: Getting signing cert info for ca from NSS database
INFO: Getting ocsp_signing cert info for ca from CS.cfg
INFO: Getting ocsp_signing cert info for ca from NSS database
INFO: Getting sslserver cert info for ca from CS.cfg
INFO: Getting sslserver cert info for ca from NSS database
INFO: Getting subsystem cert info for ca from CS.cfg
INFO: Getting subsystem cert info for ca from NSS database
INFO: Getting audit_signing cert info for ca from CS.cfg
INFO: Getting audit_signing cert info for ca from NSS database
INFO: Fixing the following certs: ['ca_ocsp_signing', 'sslserver', 'subsystem', 'ca_audit_signing']
INFO: Stopping the instance to proceed with system cert renewal
INFO: Selftests disabled for subsystems: ca
INFO: Getting sslserver cert info for ca from CS.cfg
INFO: Getting sslserver cert info for ca from NSS database
INFO: Trying to create a new temp cert for sslserver.
INFO: Generate temp SSL certificate
INFO: Getting sslserver cert info for ca from CS.cfg
INFO: Getting sslserver cert info for ca from NSS database
INFO: CSR for sslserver has been written to /tmp/tmpg_738l5a/sslserver.csr
INFO: Getting signing cert info for ca from CS.cfg
INFO: Getting signing cert info for ca from NSS database
INFO: CA cert written to /tmp/tmpg_738l5a/ca_certificate.crt
INFO: AKI: 0x1D0F356A3E7A6968A231723231EB22DA5A01F542
INFO: Temp cert for sslserver is available at /etc/pki/pki-tomcat/certs/sslserver.crt.
INFO: Getting sslserver cert info for ca from CS.cfg
INFO: Getting sslserver cert info for ca from NSS database
INFO: Getting sslserver cert info for ca from CS.cfg
INFO: Getting sslserver cert info for ca from NSS database
INFO: Updating CS.cfg with the new certificate
INFO: Getting ocsp_signing cert info for ca from CS.cfg
INFO: Getting ocsp_signing cert info for ca from NSS database
INFO: Trying to setup a secure connection to CA subsystem.
INFO: Secure connection with CA is established.
INFO: Placing cert creation request for serial: 49
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 600, in urlopen
chunked=chunked)
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 343, in _make_request
self._validate_conn(conn)
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 849, in _validate_conn
conn.connect()
File "/usr/lib/python3.6/site-packages/urllib3/connection.py", line 356, in connect
ssl_context=context)
File "/usr/lib/python3.6/site-packages/urllib3/util/ssl_.py", line 350, in ssl_wrap_socket
context.load_cert_chain(certfile, keyfile)
ssl.SSLError: [X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:3550)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 449, in send
timeout=timeout
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 638, in urlopen
_stacktrace=sys.exc_info()[2])
File "/usr/lib/python3.6/site-packages/urllib3/util/retry.py", line 398, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:3550)'),))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/pki/server/pkiserver.py", line 119, in <module>
cli.execute(sys.argv)
File "/usr/lib/python3.6/site-packages/pki/server/pkiserver.py", line 111, in execute
super(PKIServerCLI, self).execute(args)
File "/usr/lib/python3.6/site-packages/pki/cli/__init__.py", line 204, in execute
module.execute(module_args)
File "/usr/lib/python3.6/site-packages/pki/cli/__init__.py", line 204, in execute
module.execute(module_args)
File "/usr/lib/python3.6/site-packages/pki/server/cli/cert.py", line 1154, in execute
renew=True)
File "/usr/lib/python3.6/site-packages/pki/server/__init__.py", line 1709, in cert_create
PKIServer.renew_certificate(connection, new_cert_file, serial)
File "/usr/lib/python3.6/site-packages/pki/server/__init__.py", line 202, in renew_certificate
ret = cert_client.enroll_cert(inputs=inputs, profile_id='caManualRenewal')
File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, in handler
return fn_call(inst, *args, **kwargs)
File "/usr/lib/python3.6/site-packages/pki/cert.py", line 1011, in enroll_cert
enroll_request = self.create_enrollment_request(profile_id, inputs)
File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, in handler
return fn_call(inst, *args, **kwargs)
File "/usr/lib/python3.6/site-packages/pki/cert.py", line 962, in create_enrollment_request
enrollment_template = self.get_enrollment_template(profile_id)
File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, in handler
return fn_call(inst, *args, **kwargs)
File "/usr/lib/python3.6/site-packages/pki/cert.py", line 942, in get_enrollment_template
r = self.connection.get(url, self.headers)
File "/usr/lib/python3.6/site-packages/pki/client.py", line 46, in wrapper
return func(self, *args, **kwargs)
File "/usr/lib/python3.6/site-packages/pki/client.py", line 160, in get
timeout=timeout,
File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 537, in get
return self.request('GET', url, **kwargs)
File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 524, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 637, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 514, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:3550)'),))
ERROR: HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:3550)'),))
[root@ipa2 ~]# echo "--Certificate:" && openssl x509 -noout -modulus -in
/var/lib/ipa/ra-agent.pem && echo "--Key:" && openssl rsa -noout
-modulus -in /var/lib/ipa/ra-agent.key
--Certificate:
Modulus=CBA68178847F53CC0D4A45871FEA7CCFD879D6423923DF75E557011E4C458BD5207ACBB4EAFC7A460C050878621E22406E7661105F7D8E7AF448AA1F0988C908F3173B77D87581BE7006ED09F76F0D4D736050088E986133DE851A0FB93A101AA77921CC24063A94E5076FD74D4D81139E7A2AAC61B86D07D424158CE56913ABB08C1CDBDAE35CE2D7BCEB9EF9D5A909FFF502A02E1E847DC44E8672A8889A65A721DC78FE70C24D9E12BB4E88D7AD0A49948E2BF40A22431731872ADFC3B81E368C655EB9B00DC37D04526EE2917445D2FAEBCF116821486FF088E500F12128A8D90309E8ED275CDD48E77BDE0E3358A6A81BD9DD2AD5AC6F68315C96FC50E9
--Key:
Modulus=CBA68178847F53CC0D4A45871FEA7CCFD879D6423923DF75E557011E4C458BD5207ACBB4EAFC7A460C050878621E22406E7661105F7D8E7AF448AA1F0988C908F3173B77D87581BE7006ED09F76F0D4D736050088E986133DE851A0FB93A101AA77921CC24063A94E5076FD74D4D81139E7A2AAC61B86D07D424158CE56913ABB08C1CDBDAE35CE2D7BCEB9EF9D5A909FFF502A02E1E847DC44E8672A8889A65A721DC78FE70C24D9E12BB4E88D7AD0A49948E2BF40A22431731872ADFC3B81E368C655EB9B00DC37D04526EE2917445D2FAEBCF116821486FF088E500F12128A8D90309E8ED275CDD48E77BDE0E3358A6A81BD9DD2AD5AC6F68315C96FC50E9
[root@ipa2 ~]# openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key
| openssl md5
(stdin)= 0915781edbe620c5791cda50f310c538
[root@ipa2 ~]# openssl x509 -noout -modulus -in
/var/lib/ipa/ra-agent.pem | openssl md5
(stdin)= 0915781edbe620c5791cda50f310c538
Looking at the cert and the key, they are a match and modulus also
matches. What I can't figure out is why I am seeing this error if the
key and cert match. Is it possible to have a timestamp issue, or is
there some other reason that I can't find. Any help would be greatly
appreciated.
Randy Morgan
4 years, 6 months
NFS failure after upgrade
by Petros Triantafyllidis
Hi all,
I have a setup with two servers running CenOS 7.6 which I updated
recently to ipa-server-4.6.4-10.el7.centos.6.x86_64. The update
apparently completed successfully and after that I went through the
update of several clients (ipa-client-4.6.4-10.el7.centos.6.x86_64) some
of which export kerberized nfs shares. However, after the upgrade, the
nfs shares are not accessible neither by other clients nor by servers. I
don't know if it's a coincidence, but I can access only shares exported
by a non-upgraded client.
When trying to mount by hand from server (:fidias) with admin
credentials I receive:
[root@fidias]# mount -t nfs4 -o sec=krb5 medusa:/export/teras /teras
mount.nfs4: access denied by server while mounting medusa:/export/teras
[root@fidias]# ipa-getkeytab -r -s fidias.geo.auth.gr -p
nfs/medusa.geo.auth.gr -k medusa-nfs.keytab
Failed to parse result: Insufficient access rights
Failed to get keytab
[root@fidias]# KRB5_TRACE=/dev/stderr kinit -k -t /etc/krb5.keytab
nfs/medusa.geo.auth.gr
[26055] 1567693076.930983: Resolving unique ccache of type KEYRING
[26055] 1567693076.930984: Getting initial credentials for
nfs/medusa.geo.auth.gr(a)GEO.SS.LAN
[26055] 1567693076.930985: Looked up etypes in keytab: (empty)
[26055] 1567693076.930986: Getting initial credentials for
nfs/medusa.geo.auth.gr(a)GEO.SS.LAN
[26055] 1567693076.930987: Looked up etypes in keytab: (empty)
kinit: Keytab contains no suitable keys for
nfs/medusa.geo.auth.gr(a)GEO.SS.LAN while getting initial credentials
How can this be fixed?
Thanks in advance,
Petros
--
Dr. TRIANTAFYLLIDIS PETROS
Aristotle University - Department of Geophysics, POBox 112,
54124 Thessaloniki,GREECE-TEL:+30-2310998585,FAX:2310991403
4 years, 6 months
subCA OCSP on IPA Replica
by David Etchen
Hi Guys,
I have a 2 host basic IPA setup both IPA servers are running dns & ca.
I'm running on Centos 7.6 using freeipa version 4.6.4 & dogtag version 10.5.9
I've made a subCA called vpnca and a certificate policy and all this is working fine with the exception of OCSP on the 2nd IPA box.
The original master works fine and issues OCSP responses for certifcates issued by the vpnca (subCA) however the replica IPA box fails to respond.
I've had a look through the logs and found in the /var/log/pki/pki-tomcat/ca/debug log an error on the 2nd box when doing an OCSP request against it for a certificate issued by the subCA.
I should note here that OCSP requests for certificates issued by the main IPA CA work fine it's only for ones issued by the subCA on the replica that seem to be broken.
I have also spotted the 2nd IPA server complaining that is can't get caSigningCert
[04/Sep/2019:13:24:01][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Running ExternalProcessKeyRetriever
[04/Sep/2019:13:24:01][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: About to execute command: [/usr/libexec/ipa/ipa-pki-retrieve-key, caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93, man-fb-ipa-01.testhost.com]
[04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Failed to retrieve key from any host.
[04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: KeyRetriever did not return a result.
[04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Retrying in 1946 seconds
I'm presuming this is the reason OCSP is failing as it can't sign the response for the subCA?
Does anyone know if this is a known issue or if there is something I need to modify to get the OCSP working on the replica host?
Any help would be greatly appreciated
Thanks
Dave
See logs below.
2nd IPA Replica (Broken) /var/log/pki/pki-tomcat/ca/debug
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet:service() uri = /ca/ocsp
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: caOCSP start to service.
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: IP: 10.128.164.2
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: no authMgrName
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.authorize(DirAclAuthz)
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditSubjectID
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.164.2}
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditSubjectID: subjectID: null
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditGroupID
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditGroupID auditContext {locale=en_GB, ipAddress=10.128.164.2}
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditGroupID: groupID: null
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn()
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: AAclAuthz.checkPermission(certServer.ee.request.ocsp, submit)
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: checkAllowEntries(): expressions: ipaddress=".*"
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: evaluating expressions: ipaddress=".*"
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: evaluated expression: ipaddress=".*" to be true
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: DirAclAuthz: authorization passed
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: SignedAuditLogger: event AUTHZ
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: Servlet Path: /ocsp
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: RequestURI: /ca/ocsp
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: PathInfo: null
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: HTTP method: POST
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: processing POST request
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: decoding request
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: validating request
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn()
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true
[04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn()
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CertificateAuthority: validating OCSP request
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CertificateAuthority: processing request for cert 0x1b
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn()
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3
java.lang.NullPointerException
at com.netscape.ca.CertificateAuthority.getResponderIDByName(CertificateAuthority.java:2340)
at com.netscape.ca.CertificateAuthority.validate(CertificateAuthority.java:2473)
at com.netscape.ca.CertificateAuthority.validate(CertificateAuthority.java:2428)
at com.netscape.cms.servlet.ocsp.OCSPServlet.process(OCSPServlet.java:222)
at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:493)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditSubjectID
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.164.2}
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditSubjectID: subjectID: null
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: SignedAuditLogger: event OCSP_GENERATION
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: response is null
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.java: renderTemplate
[04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: curDate=Wed Sep 04 12:25:14 BST 2019 id=caOCSP time=213
If I look at 1st IPA server which is working I see
1st IPA Master (Working) /var/log/pki/pki-tomcat/ca/debug
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet:service() uri = /ca/ocsp
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: caOCSP start to service.
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: IP: 10.128.167.2
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: no authMgrName
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet.authorize(DirAclAuthz)
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditSubjectID
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.167.2}
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditSubjectID: subjectID: null
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditGroupID
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditGroupID auditContext {locale=en_GB, ipAddress=10.128.167.2}
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditGroupID: groupID: null
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn()
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 2
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 3
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: AAclAuthz.checkPermission(certServer.ee.request.ocsp, submit)
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: checkAllowEntries(): expressions: ipaddress=".*"
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: evaluating expressions: ipaddress=".*"
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: evaluated expression: ipaddress=".*" to be true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: DirAclAuthz: authorization passed
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: event AUTHZ
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: Servlet Path: /ocsp
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: RequestURI: /ca/ocsp
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: PathInfo: null
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: HTTP method: POST
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: processing POST request
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: decoding request
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: validating request
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn()
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn()
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CertificateAuthority: validating OCSP request
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CertificateAuthority: processing request for cert 0x1b
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn()
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: adding signature
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Getting algorithm context for SHA256withRSA RSASignatureWithSHA256Digest
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Signing Certificate
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditSubjectID
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.167.2}
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditSubjectID: subjectID: null
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: event OCSP_GENERATION
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Request:
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: MGwwaqADAgEAMD4wPDA6MAkGBSsOAwIaBQAEFK377uGJz9Owh8lyIT07pU1YHAEs^M
BBTDA9mf27XJPVL0EOy+SaFKAxCZhAIBG6IjMCEwHwYJKwYBBQUHMAECBBIEEJMj^M
ZAn0Vjd91e0eZdmHXyo=^M
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Serial Number: 27
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Response Size:
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: 2364
[04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Response Data:
**SNIP**
4 years, 6 months
Problems joining an Ubuntu client to IPA server and using AD Credentials
by Jokinen Eemeli
Hi!
I have a problem I could use help on resolving:
We have a working IPA Cluster and I try to join in with Ubuntu 16.04 freeipa-client. Everything seems to go smoothly, it creates config files that look just right. However when I try to login with SSH using AD Credentials I've joined the IPA with I can't login and auth.log gives me an error
--
Sep 5 15:46:29 testcomputer2 sshd[1907]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<ip> user=<user>@<ad.domain>
Sep 5 15:46:29 testcomputer2 sshd[1907]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<ip> user=<user>@<ad.domain>
Sep 5 15:46:29 testcomputer2 sshd[1907]: pam_sss(sshd:auth): received for user <user>@<ad.domain>: 4 (System error)
Sep 5 15:46:31 testcomputer2 sshd[1907]: Failed password for <user>@<ad.domain> from <ip> port 42416 ssh2
--
Couldn't find anything solid but then I turned on debug levels and looked into krb5_child.log. Our ipadomain is ipa.company.domain but for some reason it tries to find the username from company.domain and of course it can't find the username there.
--
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [tgt_req_child] (0x1000): Attempting to get a TGT
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [<company.domain>]
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.927017: Getting initial credentials for <user>@<company.domain>
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.927076: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_<ipa.company.domain>
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.927109: Retrieving host/testcomputer2.<ipa.company.domain>@<ipa.company.domain> -> krb5_ccache_conf_data/fast_avail/krbtgt\/<company.domain>\@<company.domain>@X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_<ipa.company.domain> with result: -1765328243/Matching credential not found
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.927151: Sending request (172 bytes) to <company.domain>
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938377: Retrying AS request with master KDC
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938418: Getting initial credentials for <user>@<company.domain>
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938442: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_<ipa.company.domain>
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938467: Retrieving host/testcomputer2.<ipa.company.domain>@<ipa.company.domain> -> krb5_ccache_conf_data/fast_avail/krbtgt\/<company.domain>\@<company.domain>@X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_<ipa.company.domain> with result: -1765328243/Matching credential not found
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938511: Sending request (172 bytes) to <company.domain> (master)
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [get_and_save_tgt] (0x0020): 1232: [-1765328230][Cannot find KDC for realm "<company.domain>"]
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [map_krb5_error] (0x0020): 1301: [-1765328230][Cannot find KDC for realm "<company.domain>"]
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [k5c_send_data] (0x0200): Received error code 1432158209
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [pack_response_packet] (0x2000): response packet size: [4]
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [k5c_send_data] (0x4000): Response sent.
(Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [main] (0x0400): krb5_child completed successfully
--
Seems like it converts ad.domain to company.domain and not to ipa.company.domain for some reason. But like I said the configuration on /var/lib/sss/pubconf/krb5.include.d seems legit.
--
[domain_realm]
.<ad.domain> = <AD.DOMAIN>
<ad.domain> = <AD.DOMAIN>
[capaths]
<AD.DOMAIN> = {
<IPA.COMPANY.DOMAIN> = <AD.DOMAIN>
}
<IPA.COMPANY.DOMAIN> = {
<AD.DOMAIN> = <AD.DOMAIN>
}
--
Any ideas why it's dropping the subdomain out?
Eemeli
4 years, 6 months
Certmonger managed certificate signed by sub-ca
by Ben Rawson
I'm having some trouble getting sub-ca signed certificates issued and managed by certmonger. The implementation here [https://www.freeipa.org/page/V4/Sub-CAs] describes how that should work. I see that the -X option can be passed to ipa-getcert to specify the issuer, but every time I create a request with -X specified I get an error.
Steps to reproduce:
1. Create a new CA named "Test" through the FreeIPA web UI.
2. Run the following on a host enrolled in freeIPA:
ipa-getcert request -k /root/test.key -f /root/test.crt -I "testrequest" -X "Test"
3. Run ipa-getcert list and receive the an error message:
Request ID 'test':
status: CA_REJECTED
ca-error: Server at https://ipa02.mgmt.crosschx.com/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. ).
stuck: yes
key pair storage: type=FILE,location='/root/test.key'
certificate: type=FILE,location='/root/test.crt'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
Running FreeIPA 4.6.4
Thanks for the help!
4 years, 6 months
KrbException: Identifier doesn't match expected value (906)
by lune voo
Hello everyone.
I am using a old version of IPA (3.0) on a RHEL6.6. (I know it is old ^_^).
I send you this mail because I had a problem during the night during the
execution of a spark job.
The error which occured was the following :
19/09/05 03:06:01 INFO Client: Application report for <MYAPPLICATION>
(state: FINISHED)
19/09/05 03:06:01 INFO Client:
client token: N/A
diagnostics: N/A
ApplicationMaster host: <APPMASTERIP>
ApplicationMaster RPC port: 0
queue: <QUEUE>
start time: 1567040464637
final status: SUCCEEDED
tracking URL: http://<RM_HOST>:<RM_PORT>/proxy/<MYAPPLICATION2>/
user: <myuser>
Exception in thread "main" java.io.IOException: Login failure for <myuser>
from keytab <LOCAL_PATH_FOR_KEYTAB>/<myuser>.headless.keytab:
javax.security.auth.login.LoginException: Generic error (description in
e-text) (60) - HANDLE_AUTHDATA
at
org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytabAndReturnUGI(UserGroupInformation.java:1351)
at
org.apache.spark.deploy.yarn.Client.cleanupStagingDir(Client.scala:210)
at
org.apache.spark.deploy.yarn.Client.monitorApplication(Client.scala:1204)
at org.apache.spark.deploy.yarn.Client.run(Client.scala:1258)
at org.apache.spark.deploy.yarn.Client$.main(Client.scala:1307)
at org.apache.spark.deploy.yarn.Client.main(Client.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.spark.deploy.SparkSubmit$.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:751)
at
org.apache.spark.deploy.SparkSubmit$.doRunMain$1(SparkSubmit.scala:187)
at
org.apache.spark.deploy.SparkSubmit$.submit(SparkSubmit.scala:212)
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:126)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
Caused by: javax.security.auth.login.LoginException: Generic error
(description in e-text) (60) - HANDLE_AUTHDATA
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:804)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at
javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at
javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at
javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at
org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytabAndReturnUGI(UserGroupInformation.java:1340)
... 14 more
Caused by: KrbException: Generic error (description in e-text) (60) -
HANDLE_AUTHDATA
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:82)
at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:316)
at
sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:776)
... 27 more
Caused by: KrbException: Identifier doesn't match expected value (906)
at sun.security.krb5.internal.KDCRep.init(KDCRep.java:140)
at sun.security.krb5.internal.ASRep.init(ASRep.java:64)
at sun.security.krb5.internal.ASRep.<init>(ASRep.java:59)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:60)
... 30 more
19/09/05 03:06:01 INFO ShutdownHookManager: Shutdown hook called
The error occurred after the end of a spark job in fact.
I was wondering if this kind of error means something for you ?
I checked on google and saw the problem could come :
1. from the krb5.conf file
2. from the keytab
3. from the fact that the login of <myuser> is mispelled during the TGT
step
4. from the encryption between the client and the server
As a note at the beginning of the job, there is a kinit performed on this
host and the kinit is OK.
So I checked the krb5.conf and it is OK.
I checked the keytab file and it is OK.
I was wondering if I could see maybe more information on the client side.
Do you know where are located the logs on the client side please ?
Do you know which logs I could check on server side please ?
Best regards.
Lune.
4 years, 6 months