mjg2xw
New Member.
530 views

Problem with setting up HTTPS for the User App."

Hi

Trying to setup User App. to use HTTPS. Get this error in the cataline.out log

IDM 4.7.2 AE on Windows Server 2016
The User App is acceptiong the https url and give me the option to sign in, but the sign-in process failed

2019-04-03 12:12:18,290 [ERROR] OAuthServlet [RBPM] An error occurred while attempting to contact the authentication service.
com.novell.common.auth.ValidationException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Could not determine revocation status
at com.netiq.idm.auth.oauth.OAuthServlet.handleAuthorizationResponse(OAuthServlet.java:187)


Tomcat Cataline.out...

certpath: ForwardBuilder.getMatchingCerts()...
certpath: ForwardBuilder.getMatchingEECerts()...
certpath: X509CertSelector.match(SN: b05b8b3213bc8067b6b8dd7306bcca1
Issuer: CN=GeoTrust RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US
Subject: CN=\2A.intern.vejenkommune.dk, OU=IT, O=Vejen Kommune, L=Vejen, C=DK)
certpath: X509CertSelector.match: subject DNs don't match
certpath: ForwardBuilder.getMatchingCACerts()...
certpath: ForwardBuilder.getMatchingCACerts(): the target is a CA
certpath: X509CertSelector.match(SN: 546fe1823f7e1941da39fce14c46173
Issuer: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Subject: CN=GeoTrust RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US)
certpath: X509CertSelector.match returning: true
certpath: RejectKeySelector.match: bad key
certpath: X509CertSelector.match(SN: b05b8b3213bc8067b6b8dd7306bcca1
Issuer: CN=GeoTrust RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US
Subject: CN=\2A.intern.vejenkommune.dk, OU=IT, O=Vejen Kommune, L=Vejen, C=DK)
certpath: X509CertSelector.match: subject DNs don't match
certpath: ForwardBuilder.getMatchingCACerts: found 0 CA certs
certpath: SunCertPathBuilder.depthFirstSearchForward(): certs.size=0
certpath: SunCertPathBuilder.engineBuild: 2nd pass; try building again searching all certstores
certpath: SunCertPathBuilder.buildForward()...
certpath: SunCertPathBuilder.depthFirstSearchForward(CN=GeoTrust RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US, State [
issuerDN of last cert: null
traversedCACerts: 0
init: true
keyParamsNeeded: false
subjectNamesTraversed:
[]]
)
certpath: ForwardBuilder.getMatchingCerts()...
certpath: ForwardBuilder.getMatchingEECerts()...
certpath: X509CertSelector.match(SN: b05b8b3213bc8067b6b8dd7306bcca1
Issuer: CN=GeoTrust RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US
Subject: CN=\2A.intern.vejenkommune.dk, OU=IT, O=Vejen Kommune, L=Vejen, C=DK)
certpath: X509CertSelector.match: subject DNs don't match
certpath: ForwardBuilder.getMatchingCACerts()...
certpath: ForwardBuilder.getMatchingCACerts(): the target is a CA
certpath: X509CertSelector.match(SN: 546fe1823f7e1941da39fce14c46173
Issuer: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Subject: CN=GeoTrust RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US)
certpath: X509CertSelector.match returning: true
certpath: RejectKeySelector.match: bad key
certpath: X509CertSelector.match(SN: b05b8b3213bc8067b6b8dd7306bcca1
Issuer: CN=GeoTrust RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US
Subject: CN=\2A.intern.vejenkommune.dk, OU=IT, O=Vejen Kommune, L=Vejen, C=DK)
certpath: X509CertSelector.match: subject DNs don't match
certpath: ForwardBuilder.getMatchingCACerts: found 0 CA certs
certpath: SunCertPathBuilder.depthFirstSearchForward(): certs.size=0
certpath: AdaptableX509CertSelector.match: subject key IDs don't match. Expected: [4, 20, -112, 88, -1, -80, -100, 117, -88, 81, 84, 119, -79, -19, -14, -93, 67, 22, 56, -98, 108, -59] Cert's: [4, 20, -39, 119, 2, 33, 123, -94, 52, -40, -35, 22, -9, -36, -84, 103, -29, 6, -50, -119, -103, -48]
certpath: NO - don't try this trustedCert
certpath: AdaptableX509CertSelector.match: subject key IDs don't match. Expected: [4, 20, -112, 88, -1, -80, -100, 117, -88, 81, 84, 119, -79, -19, -14, -93, 67, 22, 56, -98, 108, -59] Cert's: [4, 20, -46, 111, -9, -106, -12, -123, 63, 114, 60, 48, 125, 35, -38, -123, 120, -101, -93, 124, 90, 124]
certpath: NO - don't try this trustedCert
2019-04-03 12:12:18,290 [ERROR] OAuthServlet [RBPM] An error occurred while attempting to contact the authentication service.
com.novell.common.auth.ValidationException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Could not determine revocation status
at com.netiq.idm.auth.oauth.OAuthServlet.handleAuthorizationResponse(OAuthServlet.java:187)



Best regards
Michael
Labels (1)
0 Likes
12 Replies
Micro Focus Expert
Micro Focus Expert

Re: Problem with setting up HTTPS for the User App."

On 2019-04-03 12:34, mJg2XW wrote:>
> Hi
>
> Trying to setup User App. to use HTTPS. Get this error in the
> cataline.out log
>
> IDM 4.7.2 AE on Windows Server 2016
> The User App is acceptiong the https url and give me the option to sign
> in, but the sign-in process failed
>
> 2019-04-03 12:12:18,290 [ERROR] OAuthServlet [RBPM] An error occurred
> while attempting to contact the authentication service.
> com.novell.common.auth.ValidationException:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path validation failed:
> java.security.cert.CertPathValidatorException: Could not determine
> revocation status
> at
>

com.netiq.idm.auth.oauth.OAuthServlet.handleAuthorizationResponse(OAuthServlet.java:187)


Does the HTTPS connector in Tomcat send the server certificate as well
as the intermediate certificate (GeoTrust RSA CA 2018)?

Do you trust the DigiCert Global Root CA in your truststores?
Specifically in {com.netiq.idm.osp.ssl-keystore.file}


--
Norbert
0 Likes
mjg2xw
New Member.

Re: Problem with setting up HTTPS for the User App."

Hi

Does the HTTPS connector in Tomcat send the server certificate as well
as the intermediate certificate (GeoTrust RSA CA 2018)? -> What do you mean by this?

Do you trust the DigiCert Global Root CA in your truststores? -> YES
Specifically in {com.netiq.idm.osp.ssl-keystore.file}
0 Likes
Knowledge Partner
Knowledge Partner

Re: Problem with setting up HTTPS for the User App."

On 4/3/2019 8:06 AM, mJg2XW wrote:
>
> Hi
>
> Does the HTTPS connector in Tomcat send the server certificate as well
> as the intermediate certificate (GeoTrust RSA CA 2018)? -*> What do you
> mean by this?*
>
> Do you trust the DigiCert Global Root CA in your truststores? *-> YES*
> Specifically in {com.netiq.idm.osp.ssl-keystore.file}


I am of the belief that overkill in terms of trusting certs in keystores
cannot hurt.

There are 2-3 keystores.

JRE cacerts (/opt/netiq/idm/apps/jre/lib/security/cacerts)
OSP's look in your ism-configuration.properties file for the path
Tomcat's keystore for the private key.

Steve disagrees and takes a more, just what you need approach, which I
accept, but it is easier to just import in all of them.

So into each of those three keystores I simply import as -trustcacerts
flagged:
1) eDir tree's CA public key
2) Tomcat's public key of all the CA's, intermediate CA's, in the cert
chain.
3) OSP's certs public key (since it is almost always self signed, so its
key is the signing key).
4) cacerts - which if you do first, keytool will note that the certs are
already in the system store, but do it anyway.
5) NAM's SAML signing key public key (Optional if doing SAML)

This normally solves the vast majority of cert issues.


0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Problem with setting up HTTPS for the User App."

On 2019-04-03 15:47, Geoffrey Carman wrote:
> Tomcat's keystore for the private key.


For the Authorizaion Code Grant Oauth flow the OAuthServlet does a back
channel request to OSP's token end point. Since that is an https
connection as well, it needs to validate the server cert. To do so it
builds a cert path using the {com.netiq.idm.osp.ssl-keystore.file}
*truststore*.

In a default install {com.netiq.idm.osp.ssl-keystore.file} points to
tomcat.ks - tomcat's *keystore*. Therefore this store also needs to have
the root CA certificate.

--
Norbert
0 Likes
jrmhscht Super Contributor.
Super Contributor.

Re: Problem with setting up HTTPS for the User App."

I find this to be confusing and even annoying. Configupdate allows you to configure a trust store yet this call is hardcoded to use the tomcat keystore. This design is why we have to default to putting all certificates used in all the keystore files.

Perhaps I'm just a bit angry from fighting this for the last week doing a 4.6.1>4.7.2 upgrade as well as ID Gov 3.5 installs.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Problem with setting up HTTPS for the User App."

Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
> On 4/3/2019 8:06 AM, mJg2XW wrote:
>>
>> Hi
>>
>> Does the HTTPS connector in Tomcat send the server certificate as well
>> as the intermediate certificate (GeoTrust RSA CA 2018)? -*> What do you
>> mean by this?*
>>
>> Do you trust the DigiCert Global Root CA in your truststores? *-> YES*
>> Specifically in {com.netiq.idm.osp.ssl-keystore.file}

>
> I am of the belief that overkill in terms of trusting certs in keystores
> cannot hurt.
>
> There are 2-3 keystores.
>
> JRE cacerts (/opt/netiq/idm/apps/jre/lib/security/cacerts)
> OSP's look in your ism-configuration.properties file for the path
> Tomcat's keystore for the private key.
>
> Steve disagrees and takes a more, just what you need approach, which I
> accept, but it is easier to just import in all of them.
>
> So into each of those three keystores I simply import as -trustcacerts
> flagged:
> 1) eDir tree's CA public key
> 2) Tomcat's public key of all the CA's, intermediate CA's, in the cert
> chain.
> 3) OSP's certs public key (since it is almost always self signed, so its
> key is the signing key).
> 4) cacerts - which if you do first, keytool will note that the certs are
> already in the system store, but do it anyway.
> 5) NAM's SAML signing key public key (Optional if doing SAML)
>
> This normally solves the vast majority of cert issues.
>


We had a weird issue which was resolved by configuring OSP to not use same
keystore for both private key as for public key used for tomcat’s tls.


We had originally lazily created one keystore that container public tls
cert plus OSP private and used that in both places.

Support meant it was a bug. However guessing Steve has been burnt by such
edge cases and sticks with the documented tested approach.


Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Problem with setting up HTTPS for the User App."

On 4/3/2019 10:58 AM, Alex McHugh wrote:
> Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
>> On 4/3/2019 8:06 AM, mJg2XW wrote:
>>>
>>> Hi
>>>
>>> Does the HTTPS connector in Tomcat send the server certificate as well
>>> as the intermediate certificate (GeoTrust RSA CA 2018)? -*> What do you
>>> mean by this?*
>>>
>>> Do you trust the DigiCert Global Root CA in your truststores? *-> YES*
>>> Specifically in {com.netiq.idm.osp.ssl-keystore.file}

>>
>> I am of the belief that overkill in terms of trusting certs in keystores
>> cannot hurt.
>>
>> There are 2-3 keystores.
>>
>> JRE cacerts (/opt/netiq/idm/apps/jre/lib/security/cacerts)
>> OSP's look in your ism-configuration.properties file for the path
>> Tomcat's keystore for the private key.
>>
>> Steve disagrees and takes a more, just what you need approach, which I
>> accept, but it is easier to just import in all of them.
>>
>> So into each of those three keystores I simply import as -trustcacerts
>> flagged:
>> 1) eDir tree's CA public key
>> 2) Tomcat's public key of all the CA's, intermediate CA's, in the cert
>> chain.
>> 3) OSP's certs public key (since it is almost always self signed, so its
>> key is the signing key).
>> 4) cacerts - which if you do first, keytool will note that the certs are
>> already in the system store, but do it anyway.
>> 5) NAM's SAML signing key public key (Optional if doing SAML)
>>
>> This normally solves the vast majority of cert issues.
>>

>
> We had a weird issue which was resolved by configuring OSP to not use same
> keystore for both private key as for public key used for tomcat’s tls.
>
>
> We had originally lazily created one keystore that container public tls
> cert plus OSP private and used that in both places.
>
> Support meant it was a bug. However guessing Steve has been burnt by such
> edge cases and sticks with the documented tested approach.


No doubt, but I start with this, since it seems to resolve most issues,
most of the time.


0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Problem with setting up HTTPS for the User App."

On 2019-04-03 14:06, mJg2XW wrote:
> Does the HTTPS connector in Tomcat send the server certificate as well
> as the intermediate certificate (GeoTrust RSA CA 2018)? -*> What do you
> mean by this?*


Besides its own server certificate, Tomcat must also send all
intermediate certificates in its "Server Certificate" message according
to the TLS spec:

https://tools.ietf.org/html/rfc5246#section-7.4.2

certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.

You can check this with openssl's s_client utility and the -showcerts
parameter. So for Google the server provides the depth=0 and depth=1
certificates. The root CA certificate (depth=2) must be in the
applications truststore and is not transmitted.


# true | openssl s_client -connect www.google.com:443 -showcerts
CONNECTED(00000003)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN =
www.google.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-----BEGIN CERTIFICATE-----
MIIEijCCA3KgAwIBAgIQdCea9tmy/T6rK/dDD1isujANBgkqhkiG9w0BAQsFADBU
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMSUw
IwYDVQQDExxHb29nbGUgSW50ZXJuZXQgQXV0aG9yaXR5IEczMB4XDTE5MDMwMTA5
MjYyNFoXDTE5MDUyNDA5MjQwMFowaDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNh
bGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2ds
ZSBMTEMxFzAVBgNVBAMMDnd3dy5nb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAttbZFEIB/gbgVh08AoR4+KlJHioNp1ezSf3ZVahFUzJt
oxppi/d/sEcBplBWJEiSs2EqqgpK8WqsT/de7RfUc0ur2Cp+aPbWH3FnfASbXSj1
t+MbtdzekLwd/YfuFUARYX8FKlrA5J/sIDdd3bmyAWCYv147sRVeUoiA1YhJ0r/X
F86wiVKuxtrcZriSr5jlgDI8nCOYvf6HKFKgyhjlURNmDfn5JgWWIJ9Qv4cE5okm
QRBNl4zQxSQehi7DEXFYsMLrtyJLAbU59ZWgrAKfRrHwac0k8jk+4tl0plBZPgQG
KWGBxxgJLv57Z+QyhYncWsp8RGsgsCTEGt5jKHGA8QIDAQABo4IBQjCCAT4wEwYD
VR0lBAwwCgYIKwYBBQUHAwEwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYI
KwYBBQUHAQEEXDBaMC0GCCsGAQUFBzAChiFodHRwOi8vcGtpLmdvb2cvZ3NyMi9H
VFNHSUFHMy5jcnQwKQYIKwYBBQUHMAGGHWh0dHA6Ly9vY3NwLnBraS5nb29nL0dU
U0dJQUczMB0GA1UdDgQWBBSGwtmdiuyB73xdMZ49+W2kdLk1dzAMBgNVHRMBAf8E
AjAAMB8GA1UdIwQYMBaAFHfCuFCaZ3Z2sS3ChtCDoH6mfrpLMCEGA1UdIAQaMBgw
DAYKKwYBBAHWeQIFAzAIBgZngQwBAgIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDov
L2NybC5wa2kuZ29vZy9HVFNHSUFHMy5jcmwwDQYJKoZIhvcNAQELBQADggEBAHt3
u/9Uhlu3cLVRiC0+Q99X1GeGFFxE7Osi0W4Aqr+AQ9no9el7vZd68OQb9ezoadui
wtaIbo5XMnWPo+8qISM2DfmzVCmtDxdo/V4g4AtzR80xdlFhuquPj8YX549svbHe
4Q7kIuvb0+ma0QB5ZPRcwsYT9Q5WUahlXYYV6SUlXVjy1o3X14gJN544AlhVicHS
FBByZN17M0/tJb9Aww4KO88tF26O/Exljnw49q0ZIvMo1qNY0VNuKfzmeVr4JPhK
UxBMF3WNsPx94q85TFLw+hwsH4KJ2hGggUrzIWsOkwtrNuVXaNE/Ca1DlJA/Y3EY
XDqTMVxfvpnNAHaD9s0=
-----END CERTIFICATE-----
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMFQxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxJTAjBgNVBAMTHEdvb2dsZSBJbnRlcm5ldCBBdXRob3JpdHkgRzMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKUkvqHv/OJGuo2nIYaNVW
XQ5IWi01CXZaz6TIHLGp/lOJ+600/4hbn7vn6AAB3DVzdQOts7G5pH0rJnnOFUAK
71G4nzKMfHCGUksW/mona+Y2emJQ2N+aicwJKetPKRSIgAuPOB6Aahh8Hb2XO3h9
RUk2T0HNouB2VzxoMXlkyW7XUR5mw6JkLHnA52XDVoRTWkNty5oCINLvGmnRsJ1z
ouAqYGVQMc/7sy+/EYhALrVJEA8KbtyX+r8snwU5C1hUrwaW6MWOARa8qBpNQcWT
kaIeoYvy/sGIJEmjR0vFEwHdp1cSaWIr6/4g72n7OqXwfinu7ZYW97EfoOSQJeAz
AgMBAAGjggEzMIIBLzAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHfCuFCa
Z3Z2sS3ChtCDoH6mfrpLMB8GA1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYu
MDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdv
b2cvZ3NyMjAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dz
cjIvZ3NyMi5jcmwwPwYDVR0gBDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly9wa2kuZ29vZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
HLeJluRT7bvs26gyAZ8so81trUISd7O45skDUmAge1cnxhG1P2cNmSxbWsoiCt2e
ux9LSD+PAj2LIYRFHW31/6xoic1k4tbWXkDCjir37xTTNqRAMPUyFRWSdvt+nlPq
wnb8Oa2I/maSJukcxDjNSfpDh/Bd1lZNgdd/8cLdsE3+wypufJ9uXO1iQpnh9zbu
FIwsIONGl1p3A8CgxkqI/UAih3JaGOqcpcdaCIzkBaR9uYQ1X4k2Vg5APRLouzVy
7a8IVk6wuy6pm+T7HT4LY8ibS5FEZlfAFLSW8NwsVz9SBK2Vqn1N0PIMn5xA6NZV
c7o835DLAFshEWfC7TIe3g==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2994 bytes and written 419 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
[...]
Start Time: 1554302324
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE


--
Norbert
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Problem with setting up HTTPS for the User App."

Is the revocation list available? The CRL for the eDir CA?

PKIX path validation failed: java.security.cert.CertPathValidatorException: Could not determine revocation status



Suggests it might be a problem
0 Likes
mjg2xw
New Member.

Re: Problem with setting up HTTPS for the User App."

Hi

Have now imported the RootCA (DigiCertGlobalRootCA) and the intermediate CA (GeoTrustRSACA2018) into osp.jks and into cacerts. The problem with " Could not determine revocation status" is still there


ism-configuration.properties.............

com.netiq.idm.osp.oauth-keystore.file = d:\\\\netiq\\\\idm\\\\apps\\\\osp\\\\osp.jks
DirectoryService/realms/jndi/params/KEYSTORE_PATH = D:\\netiq\\idm\\apps\\jre\\lib\\security\\cacerts


2019-04-08 20:52:49,229 [ERROR] OAuthServlet [RBPM] An error occurred while attempting to contact the authentication service.
com.novell.common.auth.ValidationException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Could not determine revocation status
at com.netiq.idm.auth.oauth.OAuthServlet.handleAuthorizationResponse(OAuthServlet.java:187)
at com.netiq.idm.auth.oauth.OAuthServlet.doGet(OAuthServlet.java:70)

Best regards
Michael
0 Likes
jrmhscht Super Contributor.
Super Contributor.

Re: Problem with setting up HTTPS for the User App."

I believe you need to import the root and intermediate certs into the tomcat.ks per klasen and my experiences:

In a default install {com.netiq.idm.osp.ssl-keystore.file} points to
tomcat.ks - tomcat's *keystore*. Therefore this store also needs to have
the root CA certificate.


I also have a digicert certificate on my load balancer and had to add "-Dcom.sun.security.enableCRLDP=true" to the JAVA_OPTS in setenv.sh to get it past the revocation error.
0 Likes
itvejen Absent Member.
Absent Member.

Re: Problem with setting up HTTPS for the User App."

jrmhscht;2498002 wrote:
I believe you need to import the root and intermediate certs into the tomcat.ks per klasen and my experiences:



I also have a digicert certificate on my load balancer and had to add "-Dcom.sun.security.enableCRLDP=true" to the JAVA_OPTS in setenv.sh to get it past the revocation error.


Hi

This solved the problem "-Dcom.sun.security.enableCRLDP=true" to the JAVA_OPTS"

Many thanks to all, for tips and tricks:D

Best regards
Michael
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.