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
Parents
  • 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
Reply
  • 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
Children
  • 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.