Bug #2411

knb MNs and CNs allow self-signed certificates to connect

Added by Rob Nahf almost 12 years ago. Updated over 9 years ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Product Version:
Story Points:


I have a self-signed certificate that succeeds in, mn.listObjects() and mn.isAuthorized() against

a) an expired certificate for the same user (signed by dataone CA) fails to establish a connection, and
b) my MobileMe certificate passed by the Safari browser fails to establish a connection

poses a security risk to the system.

also tests the same way for cn-dev, so maybe a problem with CN deployment packaging as well.


Task #2478: testConnectionLayer_SelfSignedCert() failingRejectedBen Leinfelder

Related issues

Related to Infrastructure - Story #2548: recasting untrusted certs to public poses accessibility inconsistency to users New 2012-03-27
Related to Java Client - Story #6570: libclient should give better indication of expired certificates Closed


#1 Updated by Rob Nahf almost 12 years ago

  • Subject changed from knb MNs (at least) allow self-signed certificates to connect to knb MNs and CNs allow self-signed certificates to connect

also a problem for cn-dev.

#2 Updated by Chris Jones almost 12 years ago

  • Status changed from New to In Progress
  • Target version set to Sprint-2012.09-Block.2.1

The SSL configuration for Apache has:

SSLVerifyClient optional

meaning that a client may or may not send a valid cert. If we set it to 'none', the behavior is the same. If we set it to 'require', no SSL connections will be allowed without a valid cert (limited to cilogon and dataone on the CNs, and any on the MN depending how we decide to limit the authorized CAs.

This seems black and white: either we force or don't force valid client certs - we can't have an in between that I can see.

#3 Updated by Ben Leinfelder almost 12 years ago

We have to keep it as optional or else there will not be any notion of public access -- all communication with the server will require a valid certificate.
My understanding of client certificate processing was that only client certificates signed by a CA that the server trusted would be accepted and any others would be ignored (treated as though there were no certificate at all). This makes it a little more difficult to immediately recognize why you don't have access to some protected resource, but I think it's not that bad in the grand scheme of things.
Just because you are "using a self signed cert" doesn't mean the server used it or even asked for it. At least that's what I was seeing back in the day when we first started down this client certificate road.

#4 Updated by Dave Vieglais almost 12 years ago

  • Position set to 15
  • Target version changed from Sprint-2012.09-Block.2.1 to Sprint-2012.11-Block.2.2

#5 Updated by Dave Vieglais almost 12 years ago

  • Target version deleted (Sprint-2012.11-Block.2.2)

The issue is related to he SSL handshake process. The server indicates which CAs it will trust, if the (java) client does not have a certificate that matches, then it wil continue the connection with no certificate, and so will be connecting as public. This is not a security risk (since only public content will be seen), however there should be some feedback to the user that the connection is as a public user.

It is necessary for the certificate acceptance to be optional since otherwise, as Ben indicates, all connections will require a certificate which makes all interactions significantly more complex.

Moving this issue to the backlog, since notifying the user of who they are connected as is important, but not critical for the public release.

#6 Updated by Dave Vieglais over 9 years ago

  • Start date set to 2014-10-01
  • Due date set to 2014-10-01
  • Target version set to Release Backlog

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)