IBM Verify

 View Only
Expand all | Collapse all

Debugging TLS connections

  • 1.  Debugging TLS connections

    Posted Wed October 07, 2020 04:00 PM
    I am struggling debugging a SSL connection.
    Here is what I have:
    • ISAM is the client, and LDAP is the server  (using LDAPS)
    • If I configure the connection to LDAP, everything is working fine, but if I use TLS it fails.

    I did a packet trace, and found the following, using wireshark:

    I can see that the handshake did not complete (message: Encrypted Alert), and it was in fact rejected by ISAM (in IP 10.251.40.241).
    I don't know why!

    How can I check what happened in ISAM for it to reject the TLS communication and never complete the handshake?

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------


  • 2.  RE: Debugging TLS connections

    Posted Wed October 07, 2020 04:24 PM
    Joao,

    Which part of ISAM are you trying to use?  Is this the ISAM Runtime, WRP, AAC, etc?  Generally the client will reject a connection to the server if it does not 'trust' the signer of the server certificate.  In order to establish trust you need to ensure that the CA certificate has been added to the 'trust' keyfile of the client.  Have you added the correct CA certificate to the correct keyfile?

    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------

    Original Message


  • 3.  RE: Debugging TLS connections

    Posted Wed October 07, 2020 05:17 PM
    That is exactly what I suspect.
    LDAPS, sends me a public key. This key needs to be certified, and requires a Chain of trust. From what I can see from the certificate, it requires 2 certificates in this chain. I already tried a set of certificates, and apparently only 1 is working, and my understanding is that the other one is still missing.

    As I am always asking for the right certificates and I'm given many different certificates to try if any of the work. I am getting desperate and I am loosing confidence that I am configuring ldap.conf correctly.
    So, I need an absolute proof for myself that what I am claiming is correct, and the reason for this failure is the missing certificate on the chain.

    How can I validate this? Where can I find the proof that the reason for the failure on the handshake is this missing certificate? Or is it failing for some other reason?

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------

    Original Message


  • 4.  RE: Debugging TLS connections

    Posted Wed October 07, 2020 05:22 PM
    Joao,

    Which part of ISAM are you trying to use?  Is this the ISAM Runtime, WRP, AAC, etc?

    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------

    Original Message


  • 5.  RE: Debugging TLS connections

    Posted Wed October 07, 2020 06:48 PM
    Edited by Joao Goncalves Wed October 07, 2020 06:53 PM
    I managed to make some progress.
    I'm using this connection to Federate a Repository from Active Directory
    I believe that ISAM is using openssl. So I am using a linux machine to call the LDAP server using the following command and had a similar result that i get when using "Test Connection":
    openssl s_client -connect 10.101.0.10:636 -showcerts

    This way, I can use the linux server to debug, because it is hard to do something similar in ISAM! I wish it would be easier in ISAM!

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------

    Original Message


  • 6.  RE: Debugging TLS connections

    Posted Thu October 08, 2020 02:39 AM
    Edited by Dries Eestermans Thu October 08, 2020 03:14 AM
    Hi Joao,

    I believe I've seen this behavior previously with Active Directory on Server 2016 (or higher).

    Indeed when testing via openssl s_client (or the interfaces ISAM provides for it), connection is successfully established.

    However when attempting to connect with the policy server or WebSEAL, it will throw TLS Alert (handshake_failure if I'm not mistaken, you can see that when decoding the packet further in Wireshark).

    You need to add the following configuration in ldap.conf of the Runtime Component:
    [ldap]
    ldap-ssl-set-extn-sigalg = GSK_TLS_SIGALG_RSA_WITH_SHA1,GSK_TLS_SIGALG_DSA_WITH_SHA1,GSK_TLS_SIGALG_ECDSA_WITH_SHA1,GSK_TLS_SIGALG_RSA_WITH_SHA224,GSK_TLS_SIGALG_ECDSA_WITH_SHA224,GSK_TLS_SIGALG_RSA_WITH_SHA256,GSK_TLS_SIGALG_ECDSA_WITH_SHA256,GSK_TLS_SIGALG_RSA_WITH_SHA384,GSK_TLS_SIGALG_ECDSA_WITH_SHA384,GSK_TLS_SIGALG_RSA_WITH_SHA512,GSK_TLS_SIGALG_ECDSA_WITH_SHA512​


    And after restarting the component, the TLS handshake should successfully complete.

    Hope this helps.

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------

    Original Message


  • 7.  RE: Debugging TLS connections

    Posted Thu October 08, 2020 03:03 AM
    Thanks for the information.
    But what is happening is when I execute openssl, it returns with an error also.
    The connection is using TLS V1.2 not SSL. Why whould the entry ldap-ssl-set-extn-sigalg help?

    Regarding the TLS Alert is in fact there.

    I will give it a try. By the way, on the ldap entry for the Active Directory, I set ssl-enabled = true! I am not sure if I should do this or not. It is not clear for me what this option will do!
    1. does it mean that is supports SSL besides TLS?
    2. does it meat that the connection with ldap server uses a SSL/TLS connection?

    Here is the output:
    user@localhost $ openssl s_client -connect ad.company.com:636
    CONNECTED(00000003)
    depth=1 O = COMPANY, CN = COMPANY Issuing CA 1
    verify error:num=20:unable to get local issuer certificate
    ---
    Certificate chain
    0 s:
    i:/O=COMPANY/CN=COMPANY Issuing CA 1
    1 s:/O=COMPANY/CN=COMPANY Issuing CA 1
    i:/CN=COMPANY Root CA 1
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIEnDCCA4SgAwIBAgITSQABPCmdlF7sBSqFGgABAAE8KTANBgkqhkiG9w0BAQsF
    ADApMQwwCgYDVQQKEwNDVFQxGTAXBgNVBAMTEENUVCBJc3N1aW5nIENBIDEwHhcN
    MjAwNTE5MTc0ODEwWhcNMjEwNTE5MTc0ODEwWjAAMIGfMA0GCSqGSIb3DQEBAQUA
    A4GNADCBiQKBgQDtKUv0InfFahbgg3IzT179eBMowByb2OqOESp819WjmiG/elgu
    mow6yZHkQoQm+o0Semys1GVdeenB0+5oX8dRQaaqTyzBIJyyAKyF3ZRC9c7R6OBP
    0VnMH7bTk6s9C7n1jNAfrXMEDIuAo8+LtIgxyAZS0MIytJX702gWM4uKCQIDAQAB
    o4ICaDCCAmQwOAYJKwYBBAGCNxUHBCswKQYhKwYBBAGCNxUIh/LrOoGisRGHgZsi
    h5L7FIPn7lOBbQEcAgFuAgEAMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcD
    AQYKKwYBBAGCNxQCAjALBgNVHQ8EBAMCBaAwNQYJKwYBBAGCNxUKBCgwJjAKBggr
    BgEFBQcDAjAKBggrBgEFBQcDATAMBgorBgEEAYI3FAICMB8GA1UdEQEB/wQVMBOC
    EURNQzAwNS53MmsuY3R0LnB0MB0GA1UdDgQWBBTo9wgSsjzLpHR2jHW7Gp5f/x7p
    OjAfBgNVHSMEGDAWgBTxuQ7f3T6iLfMvknc17WRzVzuJKDB1BgNVHR8EbjBsMGqg
    aKBmhjFodHRwOi8vY2RwMS5jdHQucHQvcGtpL0NUVCUyMElzc3VpbmclMjBDQSUy
    MDEuY3JshjFodHRwOi8vY2RwMi5jdHQucHQvcGtpL0NUVCUyMElzc3VpbmclMjBD
    QSUyMDEuY3JsMIHgBggrBgEFBQcBAQSB0zCB0DBABggrBgEFBQcwAoY0aHR0cDov
    L2FpYTEuY3R0LnB0L3BraS9DVFQlMjBJc3N1aW5nJTIwQ0ElMjAxKDEpLmNydDBA
    BggrBgEFBQcwAoY0aHR0cDovL2FpYTIuY3R0LnB0L3BraS9DVFQlMjBJc3N1aW5n
    JTIwQ0ElMjAxKDEpLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AxLmN0dC5w
    dC9vY3NwMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcDIuY3R0LnB0L29jc3AwDQYJ
    KoZIhvcNAQELBQADggEBAOMAfmIc7YUFpH00uHfufR3CGtbT2Esaf3xRrJ05q+yM
    tqRH7MBGwoy07QBrvSgz6+I42G37sFoD8gQQe9rSV0CEivfrSOCShjN3fiy8kSzI
    79CtZI6a6n09c/sxka9JUkUvsA8Jo1zmxz5bzsQaA7iNswKF8Bv+ka269aS/o0LS
    oMe/4ZSEBiLX/SGTiH0NuDjXXEj0x0EFD5Uomfpgv1kKZXfWAcuF7LgITZlib4x0
    KYKjgHqChmPFLyJG98/a0jCsuvr97nKwhVOBUn0TmOmuyG10NJA8auo0mMbArs/C
    1nsCtYxy9LxvLaO37JTLAQq13BvcnK2wXD7YSRfxaaM=
    -----END CERTIFICATE-----
    subject=
    issuer=/O=COMPANY/CN=COMPANY Issuing CA 1
    ---
    No client certificate CA names sent
    Client Certificate Types: RSA sign, DSA sign, ECDSA sign
    Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
    Shared Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
    Peer signing digest: SHA256
    Server Temp Key: ECDH, P-256, 256 bits
    ---
    SSL handshake has read 2734 bytes and written 427 bytes
    ---
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 1024 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
    Protocol : TLSv1.2
    Cipher : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 530400008DCE95D9C48DC4A17DA4634C6FE64011A61D01CC026C20D39784F9BF
    Session-ID-ctx:
    Master-Key: 6A37070AD2FBCBE5922089C8434FE6B29FC179498F1344E70FCD2B0868E9AC187234887972AE0032731E7783C0B4EF59
    Key-Arg : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1602140025
    Timeout : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    ---

    read:errno=104

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------

    Original Message


  • 8.  RE: Debugging TLS connections

    Posted Sun October 11, 2020 07:50 AM
    This information appears to be listed in https://www.ibm.com/support/pages/after-configured-federated-directory-ad-using-ssltls-reverse-proxy-can-not-get-started-and-also-i-can-not-login-admin-cli-secmaster

    I found it odd that this attribute does not to appear in the "ldap.conf" file, so I believe it is an undocumented option!

    I already tried this and it does NOT work! The problem is something different!

    I will keep you updated, and let you know when I get a solution for this, but any suggestion is always welcome!

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------

    Original Message


  • 9.  RE: Debugging TLS connections

    Posted Thu October 08, 2020 05:21 AM
    Hi Joao,

    In ISAM (at least in latest versions) the OpenSSL command that you used can also be run from the ISAM CLI using the "session ssl" command:

    isam.iamlab.ibm.com> tools
    isam.iamlab.ibm.com:tools> session ssl 192.168.42.111:636 -showcerts
    CONNECTED(00000005)
    depth=0 C = us, O = ibm, CN = isam
    verify error:num=18:self signed certificate
    verify return:1
    depth=0 C = us, O = ibm, CN = isam
    verify return:1
    ---
    Certificate chain
    0 s:/C=us/O=ibm/CN=isam
    i:/C=us/O=ibm/CN=isam
    ---
    ...

    In your ldap.conf, you are right to have ssl enabled.  "ssl" is used to encompass SSL and TLS in many places in the product (since it was written before TLS was available).

    If I assume you are attempting to connect this AD as a federated directory, the main thing to check is that you have the root certificate (and any intermediates not provided by the server) loaded into the keystore(s) that are being used by the Policy Server and and your Reverse Proxies for LDAP communication.  These can be identified in the ivmgrd.conf file and Reverse Proxy configuration files in ssl-keyfile entry in [ldap] stanza.

    If the configuration files above don't specify a keystore (which can be the case if the primary LDAP is non-secure) then the SSL keystore is taken from the ssl-keyfile entry in the [ldap] stanza of the ldap.conf file.

    When I set up an ISAM system I tend to create a dedicated keystore "Registry_Keystore"  where I load all the certificates needed for LDAP communication.  I then specify this keystore during runtime configuration, reverse proxy configuration, and federated directory configuration.

    Looking at the output from your OpenSSL call, it looks like the AD server is returning a server certificate and an intermediate certificate.  This means you should only need to load the Root CA certificate into the keystore(s).  Loading the server and intermediates won't matter but you MUST have the root CA.

    I hope this helps.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message