Infrastructure

The following email was sent to CJ Grady at KUBI, along with the DataONECAChain.crt file:

MIME-Version: 1.0
Received: by 10.140.29.166 with HTTP; Wed, 7 Jan 2015 14:16:06 -0800 (PST)
Date: Wed, 7 Jan 2015 15:16:06 -0700
Delivered-To: mark.servilla@gmail.com
Message-ID:
Subject: DataONE certificate failure...
From: Mark Servilla mark.servilla@gmail.com
To: cjgrady@ku.edu
Cc: Laura Moyers lmoyers1@utk.edu
Content-Type: multipart/mixed; boundary=047d7bdcadbc19e880050c1745c8

--047d7bdcadbc19e880050c1745c8
Content-Type: multipart/alternative; boundary=047d7bdcadbc19e87c050c1745c6

--047d7bdcadbc19e87c050c1745c6
Content-Type: text/plain; charset=UTF-8

Hi CJ,

My name is Mark Servilla and I work with DataONE supporting general
operations and Member Node issues. There is an issue (below; lines 20-22)
when the DataONE Coordinating Node attempts to communicate with your MN
server at https://bidataone.nhm.ku.edu when using the CN certificate. Since
the CN certificate is signed by a DataONE specific CA, the DataONE CA chain
file (attached) must be available to your web server for TLS negotiating
and certificate verification. Judging from the diagnostic information in
the curl snippet, your Apache configuration is using the default
/etc/ssl/certs directory (line 7) for CA certificates. I am wondering if
the DataONE CA chain file is missing from this directory or may have been
modified, thus making it invalid? Note that this is in reference to DataONE
Redmine ticket #6742 (https://redmine.dataone.org/issues/6742).

1 curl -v -k --cert cnode.pem "
https://bidataone.nhm.ku.edu/mn/v1/object?count=0"
2 * Hostname was NOT found in DNS cache
3 * Trying 129.237.201.57...
4 * Connected to bidataone.nhm.ku.edu (129.237.201.57) port 443 (#0)
5 * successfully set certificate verify locations:
6 * CAfile: none
7 CApath: /etc/ssl/certs
8 * SSLv3, TLS handshake, Client hello (1):
9 * SSLv3, TLS handshake, Server hello (2):
10 * SSLv3, TLS handshake, CERT (11):
11 * SSLv3, TLS handshake, Server key exchange (12):
12 * SSLv3, TLS handshake, Request CERT (13):
13 * SSLv3, TLS handshake, Server finished (14):
14 * SSLv3, TLS handshake, CERT (11):
15 * SSLv3, TLS handshake, Client key exchange (16):
16 * SSLv3, TLS handshake, CERT verify (15):
17 * SSLv3, TLS change cipher, Client hello (1):
18 * SSLv3, TLS handshake, Finished (20):
19 * SSLv3, TLS alert, Server hello (2):
20 * error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
21 * Closing connection 0
22 curl: (35) error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca

If you have any further questions or would like to discuss this via a video
conference (Google Hangout or GoToMeeting), please let me know at your
convenience.

Sincerely,
Mark

Mark Servilla
mark.servilla@gmail.com

Additional email traffic on this issue revealed that the appropriate chain file (DataONECAChain.crt) was not in the expected /etc/ssl/certs directory:

MIME-Version: 1.0
Received: by 10.140.29.166 with HTTP; Wed, 7 Jan 2015 15:37:48 -0800 (PST)
In-Reply-To: CC2C04145913A34BA69782682A953D8772070B6A@EXCH10-MBX-02.home.ku.edu
References:
CC2C04145913A34BA69782682A953D8772070B6A@EXCH10-MBX-02.home.ku.edu
Date: Wed, 7 Jan 2015 16:37:48 -0700
Delivered-To: mark.servilla@gmail.com
Message-ID:
Subject: Re: DataONE certificate failure...
From: Mark Servilla mark.servilla@gmail.com
To: "Grady, C J" cjgrady@ku.edu
Cc: Laura Moyers lmoyers1@utk.edu, "Smith, Gregory D." gsmith@ku.edu
Content-Type: multipart/alternative; boundary=001a11c1e566422127050c1869b6

--001a11c1e566422127050c1869b6
Content-Type: text/plain; charset=UTF-8

Hi CJ,

The location is defined by your Apache site configuration file
(/etc/apache2/sites-enabled/gmn-ssl.conf for default GMN deployments); for
GMN, the default location of the certificates and chain files may be either
/var/local/dataone/certs/ca or /var/local/dataone/certs/server, but again,
it depends on your Apache config. Note that this issue is really between
the client (in this case, my local curl client) and the Apache web server,
so placing the chain file in /etc/ssl/certs should
work - I'm pretty sure that GMN doesn't come into play during
the negotiation/certificate verification at this point.

I really don't know when this issue first occurred, sorry.

Here's a direct link to the chain file:
https://repository.dataone.org/software/tools/trunk/ca/DataONECAChain.crt

Sincerely,
Mark

Mark Servilla
mark.servilla@gmail.com

On Wed, Jan 7, 2015 at 3:56 PM, Grady, C J cjgrady@ku.edu wrote:

Hi Mark,

You are correct that the chain file is not present in that location. I
thought that it was configured to use a different location
(/var/local/dataone/gmn_certs). Did this just start happening or has this
never worked?

The attachment was blocked, is there another way you can send it to me?

Thanks,

CJ

As of this date (09:00 14 Jan 2015), the KUBI MN is still not accepting the CN certificate due to an "tlsv1 alert unknown ca" error.