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
  • 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â€Tms 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â€Tms 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.


Reply
  • 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â€Tms 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.


Children
No Data