frankabhinav Super Contributor.
Super Contributor.
433 views

identity application SSLHandshake error

Hi, I am trying to configure identity application inside identity governance both my applications are on https

Following steps I have followed:

identity governance
1. ./configupdate.sh
2. updated the idvault information.
3. ./opt/netiq/idm/apps/idgov/bin/configutil.sh -password P@ssw0rd123
4. Inside Authentication server detail . Specified the userapp(identity application ) ip address.

but i am getting following when testing the connection.

Unable to connect to your server: DaaS connector returned error (489): Target system error: Exception during User Application connection test: class javax.net.ssl.SSLHandshakeException
0 Likes
12 Replies
Micro Focus Expert
Micro Focus Expert

Re: identity application SSLHandshake error

On 4/22/19 10:04 AM, frankabhinav wrote:
>
> Hi, I am trying to configure identity application inside identity
> governance both my applications are on https
>
> Following steps I have followed:
>
> identity governance
> 1. ./configupdate.sh
> 2. updated the idvault information.
> 3. ./opt/netiq/idm/apps/idgov/bin/configutil.sh -password P@ssw0rd123
> 4. Inside Authentication server detail . Specified the userapp(identity
> application ) ip address.
>
> but i am getting following when testing the connection.
>
>> Unable to connect to your server: DaaS connector returned error (489):
>> Target system error: Exception during User Application connection test:
>> class javax.net.ssl.SSLHandshakeException

>
>

Greetings,

1) What is the exact version of the product that you are using?

2) Was the ID Gov's Tomcat server set-up for https before you ran the ID
Gov installer?



--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Knowledge Partner
Knowledge Partner

Re: identity application SSLHandshake error

On 4/22/2019 10:04 AM, frankabhinav wrote:
>
> Hi, I am trying to configure identity application inside identity
> governance both my applications are on https
>
> Following steps I have followed:
>
> identity governance
> 1. ./configupdate.sh
> 2. updated the idvault information.
> 3. ./opt/netiq/idm/apps/idgov/bin/configutil.sh -password P@ssw0rd123
> 4. Inside Authentication server detail . Specified the userapp(identity
> application ) ip address.
>
> but i am getting following when testing the connection.
>
>> Unable to connect to your server: DaaS connector returned error (489):
>> Target system error: Exception during User Application connection test:
>> class javax.net.ssl.SSLHandshakeException


What I would do is edit the daas-logging.xml file, and set the
com.netiq.daas from INFO/WARN to ALL (I forget what it defaults to),
then restart Tomcat and generate the error again. This might give you
more information.

489 is a generic cannot connect error. There are abunch of sub
messages that actually appear at higher log levels, alas, NetIQ chose
not to document these errors for reasons I never understand.




0 Likes
Micro Focus Expert
Micro Focus Expert

Re: identity application SSLHandshake error

On 4/22/19 4:47 PM, Geoffrey Carman wrote:
> On 4/22/2019 10:04 AM, frankabhinav wrote:
>>
>> Hi, I am trying to configure identity application inside identity
>> governance both my applications are on https
>>
>> Following steps I have followed:
>>
>> identity governance
>> 1. ./configupdate.sh
>> 2. updated the idvault information.
>> 3.  ./opt/netiq/idm/apps/idgov/bin/configutil.sh -password P@ssw0rd123
>> 4. Inside Authentication server detail . Specified the userapp(identity
>> application ) ip address.
>>
>> but i am getting following when testing the connection.
>>
>>> Unable to connect to your server: DaaS connector returned error (489):
>>> Target system error: Exception during User Application connection test:
>>> class javax.net.ssl.SSLHandshakeException

>
> What I would do is edit the daas-logging.xml file, and set the
> com.netiq.daas from INFO/WARN to ALL (I forget what it defaults to),
> then restart Tomcat and generate the error again.  This might give you
> more information.
>
> 489 is a generic cannot connect error.  There are  abunch of sub
> messages that actually appear at higher log levels, alas, NetIQ chose
> not to document these errors for reasons I never understand.
>
>
>
>

Greetings,
This situation typically happens because the certificate chain that
the Tomcat on which ID Gov is deployed upon has not been installed into
the correct keystore so that it can be utilized during the WAR to WAR
communication. Hence my questions...

--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
frankabhinav Super Contributor.
Super Contributor.

Re: identity application SSLHandshake error

Hi there steve & geoffc,

1) What is the exact version of the product that you are using?
I am using IG3.5 and IDM4.7

2) Was the ID Gov's Tomcat server set-up for https before you ran the ID
Gov installer?

No , we had it installed in HTTP. There after i moved to HTTPS(8443).

Please find the log you asked for.
[FINE] 2019-04-23 17:15:04 com.netiq.daas.daaservice.ServiceMap loadServiceInstance - [DAAS] Received request to load service: IDMPermissionTemplate-7-14-4b74acb1f4e34bab89d3310e769e1062 
[FINE] 2019-04-23 17:15:04 com.netiq.daas.daaservice.ServiceMap loadServiceInstance - [DAAS] Loaded service: IDMPermissionTemplate-7-14-4b74acb1f4e34bab89d3310e769e1062, load count: 1
[FINE] 2019-04-23 17:15:05 com.netiq.daas.daaservice.ServiceProviderMap clean - [DAAS] Collection cleaner running...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] user:
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] server: ldaps://192.168.1.xxx:636/
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] pageSizeLimit: 1000
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] uad-dn:cn=User Application Driver,cn=driverset1,o=system
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] usergroup-dn: o=data
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] account_filter: (&(objectClass=inetOrgPerson)(DirXML-Associations=*))
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] locale: en
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] strippedCert: MIIGzTCCBbWgAwIBAgIUI3nmnotf+oTYXv14k2sYNpsER1gwDQYJKoZIhvcNAQELBQAwMzEaMBgGA1UECxMRT3JnYW5pemF0aW9uYWwgQ0ExFTATBgNVBAoUDElEVkFVTFRfVFJFRTAeFw0xOTA0MDkxMDQ5MjVaFw0yMTA0MDgxMDQ5MjVaMDQxFTATBgNVBAoUDElEVkFVTFRfVFJFRTEbMBkGA1UEAxMSaWR2YXVsdC5haXRjLmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxldxleJls4K26EVfGFUrfSSQqTpYihUbil1H9RUTBJiIj1mVu918mCXj3O7KkQOKPQp5JA4ppYsDqwS/gPfTKMzsZrRzMMubT+7T7mFlt1vG1pvEArFa8nxVvEoAaODXCaQaodZ0TjLmUJf6YEcatA+rrRO85c+O+p6MKXi+RS7BgeQeBDocMRrmV8UpZPzkH4g9nj06tPO2cJdw7O8iofBDId2/MBiWeNpUw0pYrcL4z5BK/0zS7Nya1gGIXdOfbBtIXRyqLKGu7ZS+HaS7ztIc8UjH8WXvxuc0RmAgFEjGWH6rww9hZekUxBU8CzZWd+RgjHufvUdIDjxYIAzLawIDAQABo4ID1jCCA9IwHQYDVR0OBBYEFMYZ+Yn4dTgDecRmHZbST0Zu5nIcMB8GA1UdIwQYMBaAFAAr5CEL+8HdENttV5lVibdkXUTkMCMGA1UdEQQcMBqHBMCoAW+CEmlkdmF1bHQuYWl0Yy5sb2NhbDALBgNVHQ8EBAMCBaAwggHMBgtghkgBhvg3AQkEAQSCAbswggG3BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9kZXZlbG9wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0ZXMvY2VydGF0dHJzX3YxMC5odG0wggFIoBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEaAQEAMAgwBgIBAQIBADAIMAYCAQECAQACAQCiBgIBFwEB/6OCAQSgWAIBAgICAP8CAQADDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQG8N9IMBgwEAIBAAIIf/////////8BAQACBAbw30ihWAIBAgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQR/66BMBgwEAIBAAIIf/////////8BAQACBBH/roGiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIBAAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADCCAYwGA1UdHwSCAYMwggF/MCugKaAnhiVodHRwOi8vMTkyLjE2OC4xLjExMTo4MDI4L2NybC9vbmUuY3JsMF+gXaBbhllsZGFwOi8vMTkyLjE2OC4xLjExMTozODkvQ049T25lLENOPU9uZSUyMC0lMjBDb25maWd1cmF0aW9uLENOPUNSTCUyMENvbnRhaW5lcixDTj1TZWN1cml0eTAsoCqgKIYmaHR0cHM6Ly8xOTIuMTY4LjEuMTExOjgwMzAvY3JsL29uZS5jcmwwYKBeoFyGWmxkYXBzOi8vMTkyLjE2OC4xLjExMTo2MzYvQ049T25lLENOPU9uZSUyMC0lMjBDb25maWd1cmF0aW9uLENOPUNSTCUyMENvbnRhaW5lcixDTj1TZWN1cml0eTBfoF2gW6RZMFcxDDAKBgNVBAMTA09uZTEcMBoGA1UEAxMTT25lIC0gQ29uZmlndXJhdGlvbjEWMBQGA1UEAxMNQ1JMIENvbnRhaW5lcjERMA8GA1UEAxMIU2VjdXJpdHkwDQYJKoZIhvcNAQELBQADggEBAFtNfqCQhbA3gOnK8RgpimYdBcqYTPbzm1yltPE0ecpwx0tPUyPieQlW3cINyK/C8EaWi3erZJDCQhznLRLIgKu7JFO3+IrGcOdoYJxs6C2A/nRnY4LlllnANRqk6RuTPNX7f0OyZv+x/4lM/HPsSCT+KAISw+RRvmklCX/VF4rzrdvW38K3sxoUSHfmrH9XEV/FJ6eimu8Wh1IWQ1sMrYWR6IAlBQHh7kYTuem6APf0Iu0W+vjK3V5O9bSKjUla4oeFHrAX487sUiHc30GEf8B0OPMrSOJv709W+P6u21mTh5kS/JvyARJQsuaKS9xa/Xqc946EJeoyZlFhzzPbEgw=
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Bytes are valid Base64...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Type: X.509
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Subject: CN=idvault.aitc.local, O=IDVAULT_TREE
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Issuer: O=IDVAULT_TREE, OU=Organizational CA
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Setting certificate in keystore with alias 'security-certificate'
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] strippedCert: MIIDcTCCAlmgAwIBAgIES5OnCjANBgkqhkiG9w0BAQsFADBpMRAwDgYDVQQGEwdVbmtub3duMRAwDgYDVQQIEwdVbmtub3duMRAwDgYDVQQHEwdVbmtub3duMRAwDgYDVQQKEwdVbmtub3duMQ8wDQYDVQQLEwZzeXN0ZW0xDjAMBgNVBAMTBWFkbWluMB4XDTE5MDQyMjA5NTQzNVoXDTI5MDQxOTA5NTQzNVowaTEQMA4GA1UEBhMHVW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEPMA0GA1UECxMGc3lzdGVtMQ4wDAYDVQQDEwVhZG1pbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI4zScVvyZetN0e13/VNCvwTHtHoX0mBx0nQeNuLALQykQhOaXBsWnoQzjNFAI10dKOUCPEModXOVz1D3aPdS7CT+b27DAN/yNsPw2Me20hma9/NzuOuoXyNsDJsGdpj5AR/3oP2DVxP1BPdqQfw/ycq6xkwyhAN+tii8Bs2AKQw/m0vligLhzGsToujbqlF0MkIHYO0Y1CbD5cvF8llIxQv7Waww5be8bOpFAe+RABqTqv9mP7fnD/u2JNEnwD2htesdB4rF2nCzidhXEOjB/dlMqCVQGSE2huUKSc9ohHkUMpQcn3lwNtfcs5/O5Tzth9K4DN7SsfvPYWpi1rTgIUCAwEAAaMhMB8wHQYDVR0OBBYEFJQXjuI2YUbX3XJeLHGJva5ueCqKMA0GCSqGSIb3DQEBCwUAA4IBAQAV4FdQums9bv4yRihcRwvVV+2qsBoRDbb9G9FAexg8/YEHKujNmh04xGEIEwe5MEfUqw2XVEK42ygEuRY94XgPsCu5blykU6C6bg9e1Nk4nIft8vHRgO3fWfgpBaRpe/etIOZrsO0Xll/BNrbXiI1yAWD/jX49E/t6cY8nXo5wqGzS7XldKMaeuE/hH+jUbhoUsLh2pTh0vEQAW7e16hzqTlZPuzFK2XPoUoUfzfjBDHBa+IBwqoUn22KZnSFZbdZoXLG0lfIQPnHIoY20bXih7/d7mB2Uq5phI7lyyRfTfK43PmQxqz20MMJ0gHhKv0VakO7+eCK5Hcr8K0R7Chge
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Bytes are valid Base64...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Type: X.509
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Subject: CN=admin, OU=system, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Issuer: CN=admin, OU=system, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Setting certificate in keystore with alias 'ua-security-certificate'
[FINE] 2019-04-23 17:15:05 com.netiq.daas.common.SrvInstance <init> - [DAAS] New service instance. TTL: 600
[FINE] 2019-04-23 17:15:05 com.netiq.daas.common.SrvInstance resetTimeout - [DAAS] Reset timeout for service instance to TTL: 600
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMCollector <init> - [DAAS] searchBase: cn=RoleDefs,cn=RoleConfig,cn=AppConfig,cn=User Application Driver,cn=driverset1,o=system
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMCollector <init> - [DAAS] searchScope: subtree
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMCollector <init> - [DAAS] searchFilter: (objectClass=nrfRole)
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMCollector getConnection - [DAAS] in getConnection...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS <init> - [DAAS] Creating TrustManager...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS <init> - [DAAS] Setting up SSLContext environment...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS checkServerTrusted - [DAAS] In checkServerTrusted()...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] cached keyStore principal: CN=admin, OU=system, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] cached keyStore principal: O=IDVAULT_TREE, OU=Organizational CA
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Inspecting certificate chain. length is: 2
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Issuer Cert 1: O=IDVAULT_TREE, OU=Organizational CA
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Subject Cert 1: O=IDVAULT_TREE, OU=Organizational CA
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] X500 Principal1: O=IDVAULT_TREE, OU=Organizational CA
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS checkServerTrusted - [DAAS] Server certificate is trusted...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS getAcceptedIssuers - [DAAS] In getAcceptedIssuers()...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.RoleAssignments <init> - [DAAS] uaURL: https://192.168.1.33:8543/IDMProv/role/service
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS <init> - [DAAS] Creating TrustManager...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS <init> - [DAAS] Setting up SSLContext environment...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS checkServerTrusted - [DAAS] In checkServerTrusted()...
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] cached keyStore principal: CN=admin, OU=system, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] cached keyStore principal: O=IDVAULT_TREE, OU=Organizational CA
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Inspecting certificate chain. length is: 1
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Issuer Cert 0: CN=pam.aitc.local, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Subject Cert 0: CN=pam.aitc.local, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
[FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] X500 Principal0: CN=pam.aitc.local, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
[FINE] 2019-04-23 17:15:05 com.netiq.daas.daaservice.ServiceMap unloadServiceInstance - [DAAS] Received request to unload service: IDMPermissionTemplate-7-14-4b74acb1f4e34bab89d3310e769e1062
[FINE] 2019-04-23 17:15:05 com.netiq.daas.daaservice.ServiceMap unloadServiceInstance - [DAAS] Decremented load count on service: IDMPermissionTemplate-7-14-4b74acb1f4e34bab89d3310e769e1062, load count: null
[SEVERE] 2019-04-23 17:15:05 com.netiq.iac.server.rest.ConnectionService testConnection - [IG-SERVER] Test Connection error: DaaS connector returned error (489): Target system error: Exception during User Application connection test: class javax.net.ssl.SSLHandshakeException


Inside cinfiguration --> identity Manager System connection. Following error i am seeing

The following error was encountered when accessing the external RBPM system: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
0 Likes
Knowledge Partner
Knowledge Partner

Re: identity application SSLHandshake error

> Please find the log you asked for.

Ok, that trace is ccool, and WAY better than I expected. I had been
using this log level to debug DB stuff, and it is basically mandatory to
figure out what went wrong with the 48x series of errors.

This is way better than I expected!

So it seems ldap to your tree as trusted (Tree CA)

It sees a second cert you have trusted (ua-security-certificate)

Then it tries a third one, that ends in .local which is typical of AD.
(CN=pam.aitc.local)

So it looks like it does not trust the LDAP cert your AD is using?

Whose cert would that belong to? I am guess AD, but who knows how you
are configured...



> Code:
> --------------------
> [FINE] 2019-04-23 17:15:04 com.netiq.daas.daaservice.ServiceMap loadServiceInstance - [DAAS] Received request to load service: IDMPermissionTemplate-7-14-4b74acb1f4e34bab89d3310e769e1062
> [FINE] 2019-04-23 17:15:04 com.netiq.daas.daaservice.ServiceMap loadServiceInstance - [DAAS] Loaded service: IDMPermissionTemplate-7-14-4b74acb1f4e34bab89d3310e769e1062, load count: 1
> [FINE] 2019-04-23 17:15:05 com.netiq.daas.daaservice.ServiceProviderMap clean - [DAAS] Collection cleaner running...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] user:
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] server: ldaps://192.168.1.xxx:636/
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] pageSizeLimit: 1000
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] uad-dn:cn=User Application Driver,cn=driverset1,o=system
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] usergroup-dn: o=data
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] account_filter: (&(objectClass=inetOrgPerson)(DirXML-Associations=*))
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMService setConfigData - [DAAS] locale: en
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] strippedCert: MIIGzTCCBbWgAwIBAgIUI3nmnotf+oTYXv14k2sYNpsER1gwDQYJKoZIhvcNAQELBQAwMzEaMBgGA1UECxMRT3JnYW5pemF0aW9uYWwgQ0ExFTATBgNVBAoUDElEVkFVTFRfVFJFRTAeFw0xOTA0MDkxMDQ5MjVaFw0yMTA0MDgxMDQ5MjVaMDQxFTATBgNVBAoUDElEVkFVTFRfVFJFRTEbMBkGA1UEAxMSaWR2YXVsdC5haXRjLmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxldxleJls4K26EVfGFUrfSSQqTpYihUbil1H9RUTBJiIj1mVu918mCXj3O7KkQOKPQp5JA4ppYsDqwS/gPfTKMzsZrRzMMubT+7T7mFlt1vG1pvEArFa8nxVvEoAaODXCaQaodZ0TjLmUJf6YEcatA+rrRO85c+O+p6MKXi+RS7BgeQeBDocMRrmV8UpZPzkH4g9nj06tPO2cJdw7O8iofBDId2/MBiWeNpUw0pYrcL4z5BK/0zS7Nya1gGIXdOfbBtIXRyqLKGu7ZS+HaS7ztIc8UjH8WXvxuc0RmAgFEjGWH6rww9hZekUxBU8CzZWd+RgjHufvUdIDjxYIAzLawIDAQABo4ID1jCCA9IwHQYDVR0OBBYEFMYZ+Yn4dTgDecRmHZbST0Zu5nIcMB8GA1UdIwQYMBaAFAAr5CEL+8HdENttV5lVibdkXUTkMCMGA1UdEQQcMBqHBMCoAW+CEmlkdmF1bHQuYWl0Yy5sb2NhbDALBgNVHQ8EBAMCBaAwggHMBgtghkgBhvg3AQkEAQSCAbswggG3BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9kZXZlbG9wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0ZXMvY2VydGF0dHJzX3YxMC5odG0wggFIoBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEaAQEAMAgwBgIBAQIBADAIMAYCAQECAQACAQCiBgIBFwEB/6OCAQSgWAIBAgICAP8CAQADDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQG8N9IMBgwEAIBAAIIf/////////8BAQACBAbw30ihWAIBAgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQR/66BMBgwEAIBAAIIf/////////8BAQACBBH/roGiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIBAAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADCCAYwGA1UdHwSCAYMwggF/MCugKaAnhiVodHRwOi8vMTkyLjE2OC4xLjExMTo4MDI4L2NybC9vbmUuY3JsMF+gXaBbhllsZGFwOi8vMTkyLjE2OC4xLjExMTozODkvQ049T25lLENOPU9uZSUyMC0lMjBDb25maWd1cmF0aW9uLENOPUNSTCUyMENvbnRhaW5lcixDTj1TZWN1cml0eTAsoCqgKIYmaHR0cHM6Ly8xOTIuMTY4LjEuMTExOjgwMzAvY3JsL29uZS5jcmwwYKBeoFyGWmxkYXBzOi8vMTkyLjE2OC4xLjExMTo2MzYvQ049T25lLENOPU9uZSUyMC0lMjBDb25maWd1cmF0aW9uLENOPUNSTCUyMENvbnRhaW5lcixDTj1TZWN1cml0eTBfoF2gW6RZMFcxDDAKBgNVBAMTA09uZTEcMBoGA1UEAxMTT25lIC0gQ29uZmlndXJhdGlvbjEWMBQGA1UEAxMNQ1JMIENvbnRhaW5lcjERMA8GA1UEAxMIU2VjdXJpdHkwDQYJKoZIhvcNAQELBQADggEBAFtNfqCQhbA3gOnK8RgpimYdBcqYTPbzm1yltPE0ecpwx0tPUyPieQlW3cINyK/C8EaWi3erZJDCQhznLRLIgKu7JFO3+IrGcOdoYJxs6C2A/nRnY4LlllnANRqk6RuTPNX7f0OyZv+x/4lM/HPsSCT+KAISw+RRvmklCX/VF4rzrdvW38K3sxoUSHfmrH9XEV/FJ6eimu8Wh1IWQ1sMrYWR6IAlBQHh7kYTuem6APf0Iu0W+vjK3V5O9bSKjUla4oeFHrAX487sUiHc30GEf8B0OPMrSOJv709W+P6u21mTh5kS/JvyARJQsuaKS9xa/Xqc946EJeoyZlFhzzPbEgw=
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Bytes are valid Base64...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Type: X.509
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Subject: CN=idvault.aitc.local, O=IDVAULT_TREE
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Issuer: O=IDVAULT_TREE, OU=Organizational CA
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Setting certificate in keystore with alias 'security-certificate'
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] strippedCert: MIIDcTCCAlmgAwIBAgIES5OnCjANBgkqhkiG9w0BAQsFADBpMRAwDgYDVQQGEwdVbmtub3duMRAwDgYDVQQIEwdVbmtub3duMRAwDgYDVQQHEwdVbmtub3duMRAwDgYDVQQKEwdVbmtub3duMQ8wDQYDVQQLEwZzeXN0ZW0xDjAMBgNVBAMTBWFkbWluMB4XDTE5MDQyMjA5NTQzNVoXDTI5MDQxOTA5NTQzNVowaTEQMA4GA1UEBhMHVW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEPMA0GA1UECxMGc3lzdGVtMQ4wDAYDVQQDEwVhZG1pbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI4zScVvyZetN0e13/VNCvwTHtHoX0mBx0nQeNuLALQykQhOaXBsWnoQzjNFAI10dKOUCPEModXOVz1D3aPdS7CT+b27DAN/yNsPw2Me20hma9/NzuOuoXyNsDJsGdpj5AR/3oP2DVxP1BPdqQfw/ycq6xkwyhAN+tii8Bs2AKQw/m0vligLhzGsToujbqlF0MkIHYO0Y1CbD5cvF8llIxQv7Waww5be8bOpFAe+RABqTqv9mP7fnD/u2JNEnwD2htesdB4rF2nCzidhXEOjB/dlMqCVQGSE2huUKSc9ohHkUMpQcn3lwNtfcs5/O5Tzth9K4DN7SsfvPYWpi1rTgIUCAwEAAaMhMB8wHQYDVR0OBBYEFJQXjuI2YUbX3XJeLHGJva5ueCqKMA0GCSqGSIb3DQEBCwUAA4IBAQAV4FdQums9bv4yRihcRwvVV+2qsBoRDbb9G9FAexg8/YEHKujNmh04xGEIEwe5MEfUqw2XVEK42ygEuRY94XgPsCu5blykU6C6bg9e1Nk4nIft8vHRgO3fWfgpBaRpe/etIOZrsO0Xll/BNrbXiI1yAWD/jX49E/t6cY8nXo5wqGzS7XldKMaeuE/hH+jUbhoUsLh2pTh0vEQAW7e16hzqTlZPuzFK2XPoUoUfzfjBDHBa+IBwqoUn22KZnSFZbdZoXLG0lfIQPnHIoY20bXih7/d7mB2Uq5phI7lyyRfTfK43PmQxqz20MMJ0gHhKv0VakO7+eCK5Hcr8K0R7Chge
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Bytes are valid Base64...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Type: X.509
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Subject: CN=admin, OU=system, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Cert Issuer: CN=admin, OU=system, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS getCertificateKeyStore - [DAAS] Setting certificate in keystore with alias 'ua-security-certificate'
> [FINE] 2019-04-23 17:15:05 com.netiq.daas.common.SrvInstance <init> - [DAAS] New service instance. TTL: 600
> [FINE] 2019-04-23 17:15:05 com.netiq.daas.common.SrvInstance resetTimeout - [DAAS] Reset timeout for service instance to TTL: 600
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMCollector <init> - [DAAS] searchBase: cn=RoleDefs,cn=RoleConfig,cn=AppConfig,cn=User Application Driver,cn=driverset1,o=system
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMCollector <init> - [DAAS] searchScope: subtree
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMCollector <init> - [DAAS] searchFilter: (objectClass=nrfRole)
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.IDMCollector getConnection - [DAAS] in getConnection...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS <init> - [DAAS] Creating TrustManager...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS <init> - [DAAS] Setting up SSLContext environment...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS checkServerTrusted - [DAAS] In checkServerTrusted()...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] cached keyStore principal: CN=admin, OU=system, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] cached keyStore principal: O=IDVAULT_TREE, OU=Organizational CA
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Inspecting certificate chain. length is: 2
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Issuer Cert 1: O=IDVAULT_TREE, OU=Organizational CA
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Subject Cert 1: O=IDVAULT_TREE, OU=Organizational CA
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] X500 Principal1: O=IDVAULT_TREE, OU=Organizational CA
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS checkServerTrusted - [DAAS] Server certificate is trusted...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS getAcceptedIssuers - [DAAS] In getAcceptedIssuers()...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.RoleAssignments <init> - [DAAS] uaURL: https://192.168.1.33:8543/IDMProv/role/service
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS <init> - [DAAS] Creating TrustManager...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.SSLSocketFactory_ALS <init> - [DAAS] Setting up SSLContext environment...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS checkServerTrusted - [DAAS] In checkServerTrusted()...
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] cached keyStore principal: CN=admin, OU=system, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] cached keyStore principal: O=IDVAULT_TREE, OU=Organizational CA
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Inspecting certificate chain. length is: 1
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Issuer Cert 0: CN=pam.aitc.local, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] Subject Cert 0: CN=pam.aitc.local, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
> [FINEST] 2019-04-23 17:15:05 com.netiq.daas.idmservice.TrustManager_ALS isChainTrusted - [DAAS] X500 Principal0: CN=pam.aitc.local, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
> [FINE] 2019-04-23 17:15:05 com.netiq.daas.daaservice.ServiceMap unloadServiceInstance - [DAAS] Received request to unload service: IDMPermissionTemplate-7-14-4b74acb1f4e34bab89d3310e769e1062
> [FINE] 2019-04-23 17:15:05 com.netiq.daas.daaservice.ServiceMap unloadServiceInstance - [DAAS] Decremented load count on service: IDMPermissionTemplate-7-14-4b74acb1f4e34bab89d3310e769e1062, load count: null
> [SEVERE] 2019-04-23 17:15:05 com.netiq.iac.server.rest.ConnectionService testConnection - [IG-SERVER] Test Connection error: DaaS connector returned error (489): Target system error: Exception during User Application connection test: class javax.net.ssl.SSLHandshakeException
>
> --------------------
>
>
> Inside cinfiguration --> identity Manager System connection. Following
> error i am seeing
>
>
> Code:
> --------------------
> The following error was encountered when accessing the external RBPM system: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> --------------------
>
>


0 Likes
Knowledge Partner
Knowledge Partner

Re: identity application SSLHandshake error

On 4/22/2019 8:16 PM, Steven Williams wrote:
> On 4/22/19 4:47 PM, Geoffrey Carman wrote:
>> On 4/22/2019 10:04 AM, frankabhinav wrote:
>>>
>>> Hi, I am trying to configure identity application inside identity
>>> governance both my applications are on https
>>>
>>> Following steps I have followed:
>>>
>>> identity governance
>>> 1. ./configupdate.sh
>>> 2. updated the idvault information.
>>> 3.  ./opt/netiq/idm/apps/idgov/bin/configutil.sh -password P@ssw0rd123
>>> 4. Inside Authentication server detail . Specified the userapp(identity
>>> application ) ip address.
>>>
>>> but i am getting following when testing the connection.
>>>
>>>> Unable to connect to your server: DaaS connector returned error (489):
>>>> Target system error: Exception during User Application connection test:
>>>> class javax.net.ssl.SSLHandshakeException

>>
>> What I would do is edit the daas-logging.xml file, and set the
>> com.netiq.daas from INFO/WARN to ALL (I forget what it defaults to),
>> then restart Tomcat and generate the error again.  This might give you
>> more information.
>>
>> 489 is a generic cannot connect error.  There are  abunch of sub
>> messages that actually appear at higher log levels, alas, NetIQ chose
>> not to document these errors for reasons I never understand.
>>
>>
>>
>>

> Greetings,
>     This situation typically happens because the certificate chain that
> the Tomcat on which ID Gov is deployed upon has not been installed into
> the correct keystore so that it can be utilized during the WAR to WAR
> communication.  Hence my questions...


To expand on the original question, and the clarification here, the
private key osp is using (osp.jks?) and the private key that tomcat is
using, need to be trusted by tomact and osp respectivly.

So in your JRE's cacerts, you want to import the public keys of the CA's
(and the chain, intermediates, whatever) into the osp, tomcat, and
cacerts keystores.

Tomcats private key is usually publically signed, and the JRE's are
notorious for missing intermediate CA certs in their shipping cacerts
files. Osp's private key is usually self signed, so you need that certs
public key.

It is a major pain point that has been mentioned here dozens of times
now, since basically everyone runs into this during an install.



0 Likes
Micro Focus Expert
Micro Focus Expert

Re: identity application SSLHandshake error

On 4/23/19 7:25 AM, Geoffrey Carman wrote:
> On 4/22/2019 8:16 PM, Steven Williams wrote:
>> On 4/22/19 4:47 PM, Geoffrey Carman wrote:
>>> On 4/22/2019 10:04 AM, frankabhinav wrote:
>>>>
>>>> Hi, I am trying to configure identity application inside identity
>>>> governance both my applications are on https
>>>>
>>>> Following steps I have followed:
>>>>
>>>> identity governance
>>>> 1. ./configupdate.sh
>>>> 2. updated the idvault information.
>>>> 3.  ./opt/netiq/idm/apps/idgov/bin/configutil.sh -password P@ssw0rd123
>>>> 4. Inside Authentication server detail . Specified the userapp(identity
>>>> application ) ip address.
>>>>
>>>> but i am getting following when testing the connection.
>>>>
>>>>> Unable to connect to your server: DaaS connector returned error (489):
>>>>> Target system error: Exception during User Application connection
>>>>> test:
>>>>> class javax.net.ssl.SSLHandshakeException
>>>
>>> What I would do is edit the daas-logging.xml file, and set the
>>> com.netiq.daas from INFO/WARN to ALL (I forget what it defaults to),
>>> then restart Tomcat and generate the error again.  This might give
>>> you more information.
>>>
>>> 489 is a generic cannot connect error.  There are  abunch of sub
>>> messages that actually appear at higher log levels, alas, NetIQ chose
>>> not to document these errors for reasons I never understand.
>>>
>>>
>>>
>>>

>> Greetings,
>>      This situation typically happens because the certificate chain
>> that the Tomcat on which ID Gov is deployed upon has not been
>> installed into the correct keystore so that it can be utilized during
>> the WAR to WAR communication.  Hence my questions...

>
> To expand on the original question, and the clarification here, the
> private key osp is using (osp.jks?) and the private key that tomcat is
> using, need to be trusted by tomact and osp respectivly.
>
> So in your JRE's cacerts, you want to import the public keys of the CA's
> (and the chain, intermediates, whatever) into the osp, tomcat, and
> cacerts keystores.
>
> Tomcats private key is usually publically signed, and the JRE's are
> notorious for missing intermediate CA certs in their shipping cacerts
> files.  Osp's private key is usually self signed, so you need that certs
> public key.
>
> It is a major pain point that has been mentioned here dozens of times
> now, since basically everyone runs into this during an install.
>
>
>

Greetings,
What Geoffrey has outlined is not 100% correct for 3.5.x. We are not
creating different truststores and one should not be utilizing the
cacerts file any more except for 1 case that I am aware. If one
utilizes configupdate with the tomcat servers running (with https) it
(configupdate) will prompt you and "install" the certificate chain in
the correct location. I do believe I have outlined this a few times
since 3.5 shipped.

--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: identity application SSLHandshake error

On 4/23/19 8:58 AM, Steven Williams wrote:
> On 4/23/19 7:25 AM, Geoffrey Carman wrote:
>> On 4/22/2019 8:16 PM, Steven Williams wrote:
>>> On 4/22/19 4:47 PM, Geoffrey Carman wrote:
>>>> On 4/22/2019 10:04 AM, frankabhinav wrote:
>>>>>
>>>>> Hi, I am trying to configure identity application inside identity
>>>>> governance both my applications are on https
>>>>>
>>>>> Following steps I have followed:
>>>>>
>>>>> identity governance
>>>>> 1. ./configupdate.sh
>>>>> 2. updated the idvault information.
>>>>> 3.  ./opt/netiq/idm/apps/idgov/bin/configutil.sh -password P@ssw0rd123
>>>>> 4. Inside Authentication server detail . Specified the
>>>>> userapp(identity
>>>>> application ) ip address.
>>>>>
>>>>> but i am getting following when testing the connection.
>>>>>
>>>>>> Unable to connect to your server: DaaS connector returned error
>>>>>> (489):
>>>>>> Target system error: Exception during User Application connection
>>>>>> test:
>>>>>> class javax.net.ssl.SSLHandshakeException
>>>>
>>>> What I would do is edit the daas-logging.xml file, and set the
>>>> com.netiq.daas from INFO/WARN to ALL (I forget what it defaults to),
>>>> then restart Tomcat and generate the error again.  This might give
>>>> you more information.
>>>>
>>>> 489 is a generic cannot connect error.  There are  abunch of sub
>>>> messages that actually appear at higher log levels, alas, NetIQ
>>>> chose not to document these errors for reasons I never understand.
>>>>
>>>>
>>>>
>>>>
>>> Greetings,
>>>      This situation typically happens because the certificate chain
>>> that the Tomcat on which ID Gov is deployed upon has not been
>>> installed into the correct keystore so that it can be utilized during
>>> the WAR to WAR communication.  Hence my questions...

>>
>> To expand on the original question, and the clarification here, the
>> private key osp is using (osp.jks?) and the private key that tomcat is
>> using, need to be trusted by tomact and osp respectivly.
>>
>> So in your JRE's cacerts, you want to import the public keys of the
>> CA's (and the chain, intermediates, whatever) into the osp, tomcat,
>> and cacerts keystores.
>>
>> Tomcats private key is usually publically signed, and the JRE's are
>> notorious for missing intermediate CA certs in their shipping cacerts
>> files.  Osp's private key is usually self signed, so you need that
>> certs public key.
>>
>> It is a major pain point that has been mentioned here dozens of times
>> now, since basically everyone runs into this during an install.
>>
>>
>>

> Greetings,
>   What Geoffrey has outlined is not 100% correct for 3.5.x.  We are not
> creating different truststores and one should not be utilizing the
> cacerts file any more except for 1 case that I am aware.  If one
> utilizes configupdate with the tomcat servers running (with https) it
> (configupdate) will prompt you and "install" the certificate chain in
> the correct location.  I do believe I have outlined this a few times
> since 3.5 shipped.
>

Greetings,
Since you are testing a connection from within ID Gov, did you
utilize the "load certificate" button in the Collector to import the
certificate for the collector to use?

--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Knowledge Partner
Knowledge Partner

Re: identity application SSLHandshake error

> Greetings,
>   What Geoffrey has outlined is not 100% correct for 3.5.x.  We are not
> creating different truststores and one should not be utilizing the
> cacerts file any more except for 1 case that I am aware.  If one


That is great news for 3.5 (still not tried it).

So OSP and Tomcat are sharing a keystore, which is pretty easy to
configure 3.01 to do as well.

> utilizes configupdate with the tomcat servers running (with https) it
> (configupdate) will prompt you and "install" the certificate chain in
> the correct location.  I do believe I have outlined this a few times
> since 3.5 shipped.


which cert chain? I know I was surprised by configupdate doing it for
the tree CA when you browse LDAP (Which was great to learn).

0 Likes
Micro Focus Expert
Micro Focus Expert

Re: identity application SSLHandshake error

On 4/23/19 11:45 PM, Geoffrey Carman wrote:
>> Greetings,
>>    What Geoffrey has outlined is not 100% correct for 3.5.x.  We are
>> not creating different truststores and one should not be utilizing the
>> cacerts file any more except for 1 case that I am aware.  If one

>
> That is great news for 3.5 (still not tried it).
>
> So OSP and Tomcat are sharing a keystore, which is pretty easy to
> configure 3.01 to do as well.
>
>> utilizes configupdate with the tomcat servers running (with https) it
>> (configupdate) will prompt you and "install" the certificate chain in
>> the correct location.  I do believe I have outlined this a few times
>> since 3.5 shipped.

>
> which cert chain? I know I was surprised by configupdate doing it for
> the tree CA when you browse LDAP (Which was great to learn).
>

Greetings,

"
So OSP and Tomcat are sharing a keystore, which is pretty easy to
configure 3.01 to do as well.
"

That statement is incorrect.



--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: identity application SSLHandshake error

On 4/24/19 6:08 AM, Steven Williams wrote:
> On 4/23/19 11:45 PM, Geoffrey Carman wrote:
>>> Greetings,
>>>    What Geoffrey has outlined is not 100% correct for 3.5.x.  We are
>>> not creating different truststores and one should not be utilizing
>>> the cacerts file any more except for 1 case that I am aware.  If one

>>
>> That is great news for 3.5 (still not tried it).
>>
>> So OSP and Tomcat are sharing a keystore, which is pretty easy to
>> configure 3.01 to do as well.
>>
>>> utilizes configupdate with the tomcat servers running (with https) it
>>> (configupdate) will prompt you and "install" the certificate chain in
>>> the correct location.  I do believe I have outlined this a few times
>>> since 3.5 shipped.

>>
>> which cert chain? I know I was surprised by configupdate doing it for
>> the tree CA when you browse LDAP (Which was great to learn).
>>

> Greetings,
>
> "
> So OSP and Tomcat are sharing a keystore, which is pretty easy to
> configure 3.01 to do as well.
> "
>
> That statement is incorrect.
>
>
>

Greetings,
Outside of the scope for the topic that this thread was started, need
to put more clarification to aspects that were raised by Geoffrey:

Here is what one should have and is what we consider the current best
practice:

1) On a server that only has OSP you will have the following
keystore/truststore

a) jre/lib/security/cacerts file apart of the JRE (In most cases will
not be updated with certificates for an IDM 3.5 set-up)
b) osp/osp.pkcs12 -> For OSP to do its work
c) osp/osp-truststore.pkcs12 -> If OSP needed to connect out via https
d) The truststore/keystore that tomcat is using for https


2) On servers that only have ID Gov or ID Reporting you will have the
following keystore/truststore
a) jre/lib/security/cacerts file apart of the JRE (In most cases will
not be updated with certificates for an IDM 3.5 set-up)
b) /tomcat/conf/apps-truststore.pkcs12 -> For the deployed application
to utilize (like war to war communication)
c) The truststore/keystore that tomcat is using for https


Any other thoughts on this should be in a different thread.



--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Knowledge Partner
Knowledge Partner

Re: identity application SSLHandshake error

On 4/24/2019 6:08 AM, Steven Williams wrote:
> On 4/23/19 11:45 PM, Geoffrey Carman wrote:
>>> Greetings,
>>>    What Geoffrey has outlined is not 100% correct for 3.5.x.  We are
>>> not creating different truststores and one should not be utilizing
>>> the cacerts file any more except for 1 case that I am aware.  If one

>>
>> That is great news for 3.5 (still not tried it).
>>
>> So OSP and Tomcat are sharing a keystore, which is pretty easy to
>> configure 3.01 to do as well.
>>
>>> utilizes configupdate with the tomcat servers running (with https) it
>>> (configupdate) will prompt you and "install" the certificate chain in
>>> the correct location.  I do believe I have outlined this a few times
>>> since 3.5 shipped.

>>
>> which cert chain? I know I was surprised by configupdate doing it for
>> the tree CA when you browse LDAP (Which was great to learn).
>>

> Greetings,
>
> "
> So OSP and Tomcat are sharing a keystore, which is pretty easy to
> configure 3.01 to do as well.
> "
>
> That statement is incorrect.


How so? You specify the private key (By alias) for Tomcat and OSP in
their config. Why can you not have one keystore, with 2 private keys
and all the rest of the public keys?

What stops you from using the same store, so long as both are running on
the same box?


0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.