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 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

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.