Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-642

ADS does not remember the certificate if two certificates are used for the same server

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5.2
    • Fix Version/s: 1.5.3
    • Component/s: studio-connection
    • Labels:
      None
    • Environment:
      Windows Vista 32 bit

      Description

      • Install two directories on the same server
      • Configure LDAPs for both directories with differente certificate
      • Connect to the first directory with ADS by using LDAPs
      • Choose "Always trust this certificate"
      • Disconnect from the first directory
      • Connect to the second directory with ADS by using LDAP
      • Choose "Always trust this certificate"
      • Disconnect from the first directory
      • Connect to the first directory with ADS by using LDAPs
      • Although that "Always trust this certificate" has been first chosen, the popup "certificate trust" is displayed
      1. trusted-certificates.png
        49 kB
        Stefan Seelmann
      2. screenshot-2.jpg
        67 kB
        Matthieu Turpault
      3. screenshot-1.jpg
        66 kB
        Matthieu Turpault

        Activity

        Hide
        Matthieu Turpault added a comment -

        First certificate

        Show
        Matthieu Turpault added a comment - First certificate
        Hide
        Matthieu Turpault added a comment -

        Second certificate

        Show
        Matthieu Turpault added a comment - Second certificate
        Hide
        Stefan Seelmann added a comment -

        We use the subject DN as alias to store the certificates in the key store. In your case the subject DN of both certificates is equal: CN=SFIDC.Sanofi.priv

        We have to check if we can use another alias, e.g. by adding the serial number or by using the SHA1 hash.

        Show
        Stefan Seelmann added a comment - We use the subject DN as alias to store the certificates in the key store. In your case the subject DN of both certificates is equal: CN=SFIDC.Sanofi.priv We have to check if we can use another alias, e.g. by adding the serial number or by using the SHA1 hash.
        Hide
        Emmanuel Lecharny added a comment -

        Using the Serial Number is most certainly a good idea :
        "The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it issues."

        http://java.sun.com/j2se/1.5.0/docs/guide/security/cert3.html

        Show
        Emmanuel Lecharny added a comment - Using the Serial Number is most certainly a good idea : "The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it issues." http://java.sun.com/j2se/1.5.0/docs/guide/security/cert3.html
        Hide
        Stefan Seelmann added a comment -

        Using the SHA-1 hash as alias. Now it is possible to have trusted certificates with same issuer and subject, see the 3rd screenshot. As we use the subject DN in the list both entries look equal. Is this an issue? If so which information of the certificate should we display in the list?

        Show
        Stefan Seelmann added a comment - Using the SHA-1 hash as alias. Now it is possible to have trusted certificates with same issuer and subject, see the 3rd screenshot. As we use the subject DN in the list both entries look equal. Is this an issue? If so which information of the certificate should we display in the list?
        Hide
        Pierre-Arnaud Marcelot added a comment -

        I think we could add the SHA-1 fingerprint to the certificate label in the table.

        Show
        Pierre-Arnaud Marcelot added a comment - I think we could add the SHA-1 fingerprint to the certificate label in the table.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        After more thinking and discussion with Stefan over IRC, we think that leaving the table display as it is right now is probably the best solution.
        Adding the SHA-1 fingerprint we make the label way too long to be displayed correctly without having to resize the window and this kind of situation where you have multiple certificates with same subject DN is not going to happen that often.
        Adding such information might pollute the display for most users...

        Show
        Pierre-Arnaud Marcelot added a comment - After more thinking and discussion with Stefan over IRC, we think that leaving the table display as it is right now is probably the best solution. Adding the SHA-1 fingerprint we make the label way too long to be displayed correctly without having to resize the window and this kind of situation where you have multiple certificates with same subject DN is not going to happen that often. Adding such information might pollute the display for most users...
        Hide
        Matthieu Turpault added a comment -

        It should be nice if we can see the certificate from the connexion panel, by rigth-clicking on the connexion for example. Otherwise, it will be impossible to know which certificate is associated to a specific connexion.

        Show
        Matthieu Turpault added a comment - It should be nice if we can see the certificate from the connexion panel, by rigth-clicking on the connexion for example. Otherwise, it will be impossible to know which certificate is associated to a specific connexion.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Yeah, this is a good idea Matthieu.
        Unfortunately, at the moment we're not storing the association between the certificate in the keystore and the connection.
        This is definitely something that would need to be done for 2.0.

        Show
        Pierre-Arnaud Marcelot added a comment - Yeah, this is a good idea Matthieu. Unfortunately, at the moment we're not storing the association between the certificate in the keystore and the connection. This is definitely something that would need to be done for 2.0.
        Hide
        Matthieu Turpault added a comment -

        But ADS can retrieve the certificate at the first connexion. So, it should be possible to get it on demand. In this way, it can not be displayed if ADS is not on line but this feature can be evolved on a next release.

        Show
        Matthieu Turpault added a comment - But ADS can retrieve the certificate at the first connexion. So, it should be possible to get it on demand. In this way, it can not be displayed if ADS is not on line but this feature can be evolved on a next release.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Indeed, it could be interesting to have that information in the properties page associated with the connection.
        We could even store a local version of the certificate, so it can be displayed when the connection is closed.
        You really should create a new feature request (we could introduce it in 2.0 or even 1.5.4).

        Show
        Pierre-Arnaud Marcelot added a comment - Indeed, it could be interesting to have that information in the properties page associated with the connection. We could even store a local version of the certificate, so it can be displayed when the connection is closed. You really should create a new feature request (we could introduce it in 2.0 or even 1.5.4).
        Hide
        Stefan Seelmann added a comment -

        Resolving this issue, please create a new feature request to display the certificate used by a connection.

        Show
        Stefan Seelmann added a comment - Resolving this issue, please create a new feature request to display the certificate used by a connection.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Version 1.5.3 has been release.
        Let's close this issue.

        Show
        Pierre-Arnaud Marcelot added a comment - Version 1.5.3 has been release. Let's close this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Matthieu Turpault
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development