Can I test services to see the certificate it is presenting as bound to said service/port?

Follow
    Applies to:
  • SecureAuth Identity Platform
  • Legacy SecureAuth IdP
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected:  All

    Description:  

    This is not the only use case, but definitely a stickier one.

    When testing Active Directory Lightweight Directory Services (ADLDS) over SSL there seems to be no tried and tested way of seeing what certificate is actually being sent from the servers SSL port to the connecting party.

     

    Cause:  

    ADLDS can be tricky to setup and just because there is a certificate in the Computer's Personal store, it does not mean that that certificate is by default in use by ADLDS.

     

    Resolution:  

    In order to make sure a certificate is listening on the ADLDS SSL port, make sure the ADAM Service account has the certificate imported into it's Personal Store:

    Once a certificate with a private key is added and the Root is trusted, a simple restart of the service should bind the certificate but when testing and possibly running into issues, you can use openssl on a Linux system, by using Windows Subsystem for Linux on your Windows machine, or find an installation for Windows.

    Using the following command, you can test your ADLDS SSL connection to see what certificate, if there is one, is being presented.

    openssl s_client -connect myadlds.server.dom.ext:636

    You will get a response something like the following.

    root@sadebl4l01:~# openssl s_client -connect 10.0.0.7:636
    CONNECTED(00000003)
    Can't use SSL_get_servername
    depth=0 CN = server.domain.local
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 CN = server.domain.local
    verify error:num=21:unable to verify the first certificate
    verify return:1
    depth=0 CN = server.domain.local
    verify return:1
    ---
    Certificate chain
    0 s:CN = server.domain.local
    i:DC = local, DC = domain, CN = SERVER-CA
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIF/zCCBOegAwIBAgITeQAAAGomGCp3XmutVwACAAAAajANBgkqhkiG9w0BAQsF
    ...
    fHfz
    -----END CERTIFICATE-----
    subject=CN = server.domain.local

    issuer=DC = local, DC = domain, CN = SERVER-CA

    ---
    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:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
    Peer signing digest: SHA256
    Peer signature type: RSA
    Server Temp Key: ECDH, P-384, 384 bits
    ---
    SSL handshake has read 2089 bytes and written 453 bytes
    Verification error: unable to verify the first certificate
    ---
    New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    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-AES256-GCM-SHA384
    Session-ID: ...
    Session-ID-ctx:
    Master-Key: ...
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1701976732
    Timeout : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
    ---

    Although the above is edited, it shows the type of information that is returned by OpenSSL querying the ADLDS SSL port and should be enough to prove that the proper certificate is bound to the ADLDS server.

     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.