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

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}

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.

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

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

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.

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.

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

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.

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