[Einstein Toolkit] #1061: Certificate failure

List overview All Threads
Download

newer

older

[Einstein Toolkit] #815: Outlfow...

[Einstein Toolkit] #1205: Thorn...

Einstein Toolkit

27 Aug 2012 27 Aug '12

11:57 a.m.

#1061: Certificate failure -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I want to access the ET svn repositories via SourceTree, a nice GUI for managing repositories. This fails because:

Error validating server certificate for 'https://svn.einsteintoolkit.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.einsteintoolkit.org - Valid: from Thu, 05 Jan 2012 22:31:55 GMT until Fri, 04 Jan 2013 22:31:55 GMT - Issuer: lsu, edu - Fingerprint: de:b0:88:20:f7:6f:73:df:ed:ad:c2:af:7e:b7:e1:45:13:82:8a:7d (R)eject, accept (t)emporarily or accept (p)ermanently? RA layer request failed: OPTIONS of 'https://svn.einsteintoolkit.org/manifest': Server certificate verification failed: issuer is not trusted (https://svn.einsteintoolkit.org) at /Applications/SourceTree.app/Contents/Resources/git_local/libexec/git-core /git-svn line 2327

Unfortunately, as this is a GUI, I cannot press the "R" key here. To simplify things for me, could you use a trusted certificate instead?

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Show replies by date

Einstein Toolkit

27 Aug 27 Aug

1:02 p.m.

#1061: Certificate failure ------------------------------------+--------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------

Comment (by knarf):

The current certificate is correct. The question whether it is trusted is an issue of the client. Nothing on the server can ensure that an certificate is trusted. However, e.g. consulting various ssl checkers on the svn repositories show "The certificate should be trusted by all major web browsers".

Maybe the trust list on your client are not complete or out of date? There must be a way to add trusted certificates in the worst case.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:1 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

1:03 p.m.

Comment (by knarf):

E.g. try

http://www.sslshopper.com/ssl- checker.html#hostname=https://svn.einsteintoolkit.org

http://www.geocerts.com/ssl_checker

http://www.networking4all.com/en/support/tools/site+check/

http://www.digicert.com/help/

(All say "ok".)

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:2 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

2 Sep 2 Sep

11:22 p.m.

#1061: Certificate failure ------------------------------------+--------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: invalid | Keywords: ------------------------------------+--------------------------------------- Changes (by knarf):

* status: new => closed * resolution: => invalid

Comment:

Please reopen if there still is some issue with the certificate.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:3 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

16 Oct 16 Oct

12:09 p.m.

#1061: Certificate failure --------------------------------------+------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: reopened Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Resolution: | Keywords: --------------------------------------+------------------------------------- Changes (by rhaas):

* priority: major => minor * resolution: invalid => * status: closed => reopened * component: EinsteinToolkit thorn => EinsteinToolkit website

Comment:

This is partially happening again. Now Firefox is happy with the certificate for trac.einsteintoolkit.org but eg. wget is not happy with it

{{{ rhaas@horizon:.../EinsteinEOS/EOS_Omni$ wget https://trac.einsteintoolkit.org/raw- attachment/ticket/1070/EOS_Omni_Module.F90.diff --2012-10-16 10:01:49-- https://trac.einsteintoolkit.org/raw- attachment/ticket/1070/EOS_Omni_Module.F90.diff Resolving trac.einsteintoolkit.org (trac.einsteintoolkit.org)... 130.39.21.34 Connecting to trac.einsteintoolkit.org (trac.einsteintoolkit.org)|130.39.21.34|:443... connected. ERROR: The certificate of `trac.einsteintoolkit.org' is not trusted. ERROR: The certificate of `trac.einsteintoolkit.org' hasn't got a known issuer. }}}

with curl the error is:

{{{ rhaas@horizon:.../EinsteinEOS/EOS_Omni$ curl https://trac.einsteintoolkit.org/raw- attachment/ticket/1070/EOS_Omni_Module.F90.diff curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. }}}

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:4 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

17 Oct 17 Oct

9:27 a.m.

Comment (by knarf):

As said before, the question of a certificate being trusted is on the client side, not the server. We cannot do something if a client (e.g. OS vendor) decides to use an old list of 'trusted root certificates' or simply doesn't list some there. The certificate of svn.einsteintoolkit.org is valid. See e.g.

http://www.sslshopper.com/ssl- checker.html#hostname=https://trac.einsteintoolkit.org/wiki

The question really boils down to whether your system trusts the "AddTrust External CA Root" certificate by default or not.

Note that you saw a change in behavior because the certificate for trac was renewed (the old was expired) and LSU chose to sign it using "InCommon Server CA" which is signed by "AddTrust External CA Root". The old was signed by "Louisiana State University Issuing CA 1" which is signed by a different root: "GTE CyberTrust Global Root", but since "Louisiana State University Issuing CA 1" also expires Aug next year there wouldn't have been much use in choosing that.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:5 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

9:54 a.m.

#1061: Certificate failure --------------------------------------+------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: reopened Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Resolution: | Keywords: --------------------------------------+------------------------------------- Changes (by knarf):

* type: defect => enhancement

Comment:

It might be interesting to collect information about affected systems and provide solutions for users, i.e. how to tell these systems to trust this root CA.

This is probably going to be a problem primarily on old machines. The root cert in question has a validity window of December 6, 2010 to May 30, 2020 and probably simply wasn't around at the time some of the machines have been installed and thus is not trusted by default there. This is the case for instance on QueenBee.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:6 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

9:57 a.m.

Comment (by hinder):

We need to evaluate the end-to-end consequences of what we do, rather than applying a narrow definition of who is right and who is wrong. If some very popular OS has an old list of trusted root certificates, and we require a new one, then we are broken on that OS, and it doesn't really matter whose fault it is. When you buy an SSL certificate, does it come with some indication of the number of widely-deployed systems which it will work with? If you buy a cheaper certificate, will it work with fewer systems? I'm wondering if there is a financial aspect to this.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:7 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

10:29 a.m.

Comment (by knarf):

I don't think this is a financial aspect. Root certificates, like any certificate, have a life span. Older systems eventually do not only have a problem because they cannot trust new root certificates, the ones they do trust eventually all expire. For this mechanism to work the list of trusted certificates needs to be updated from time to time. There is no way for us to change this.

You say that this is a problem on a "very popular OS". Do you have more information about that OS? A lot of the tools mentioned (wget, curl) use libraries like openssl under their hood. Which version of openssl is installed there?

My current Debian system (released Feb. 2011) ships with OpenSSL 0.9.8o 01 Jun 2010. This seems to be sufficient for 'our' root certificate. QueenBee on the other hand runs RHEL 4.5, released 2007-05-01 and uses OpenSSL 0.9.7d 17 Mar 2004. Unless the list of certificates was updated in the meantime the list of trusted certificates there is over 8 years old. I don't think you will find so many root certificates that had been valid at that time, will still be in some years and are still used to sign other certificates.

The problem can really only be solved by updating the list of trusted certificates - either (ideally) by the vendor, by the system administrator, or otherwise by the user.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:8 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

10:43 a.m.

Comment (by barry.wardell):

If you would like suggestions for alternative SSL certificate suppliers, I can recommend StartSSL as a very good option. They offer free SSL certs which are accepted by any client I have tried them with. Their root certificate is only valid since September 2006, though, so it might not help with QueenBee, for example.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:9 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

10:44 a.m.

Comment (by rhaas):

Hmm. Its working now for me. Not sure why it failed before. I take it there was no change in certificate during this timeframe (from yesterday). This happened on a debian testing system which does a apt-get update && apt-get dist-upgrade each night (and which has extract certificate package as in http://curl.haxx.se/docs/caextract.html).

As long as this error does not happen during the initial GetComponents stage I am less worried. I would just like to very much make sure that things work during GetComponents (by either adding --no-check-certificate or --insecure to wget/curl).

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:10 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

10:45 a.m.

Comment (by eschnett):

If we require action from the end user, then we may as well skip certificates, which are supposed to automate this process. The information on Trac is not important enough to be worried about attackers; I'd rather clean up a bit more spam than have to explain people how to disable the security measures we put into place.

As Ian mentioned, we are probably not the only group facing this issue. Large web sites (Google, Amazon, etc.) know how to use certificates in such a way that end users don't receive warnings. I don't care about the technical issues, or how they can be solved with or without root access by the end user. We are paying for a service, and that service is to authenticate us (our server) to our visitors. If this doesn't work, then we paid too much. It's the CA's task to ensure that sufficiently many end users have received their certificate via OS updates or some other mechanism, and if that process takes five years, so be it -- apparently, a root certificate lives for ten years, so there's no problem.

If someone uses a "too-new" root certificate for signing a web site, then this seems rather like a rookie mistake to me.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:11 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

5:13 p.m.

Comment (by knarf):

I agree with Erik that we should avoid ssl if it turns out to be a problem on a critical mass of machines. So, which machines are indeed affected? So far I only know about QueenBee, as the problem seems to have disappeared for horizon. Are there other systems where this is a problem? If it turns out that only a small number of machines, especially old HPC systems, are affected we might as well ask the admins to update openssl there - especially if the new LSU certs are not accepted on LSU machines. I opened a ticket for QueenBee.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:12 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

25 Oct 25 Oct

6:39 p.m.

Comment (by knarf):

This has been fixed on QueenBee. Are there other affected machines? Can we close this ticket?

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:13 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

6:55 p.m.

#1061: Certificate failure --------------------------------------+------------------------------------- Reporter: eschnett | Owner: knarf Type: enhancement | Status: assigned Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Resolution: | Keywords: --------------------------------------+------------------------------------- Changes (by knarf):

* owner: => knarf * status: reopened => assigned

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:14 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

4 Jan 4 Jan

9:04 p.m.

#1061: Certificate failure --------------------------------------+------------------------------------- Reporter: eschnett | Owner: knarf Type: defect | Status: assigned Priority: major | Milestone: Component: EinsteinToolkit website | Version: Resolution: | Keywords: --------------------------------------+------------------------------------- Changes (by rhaas):

* priority: minor => major * type: enhancement => defect

Comment:

This certificate has now officially expired (it being after Fri, 04 Jan 2013 22:31:55 GMT). It has not been replaced by an up-to-date one. Svn and firefox complain. Frank's script warns (though it apparently does not do the proper time zone conversion): www.cct.lsu.edu/~knarf/cgi- bin/monitor.cgi

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:15 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

10:48 p.m.

#1061: Certificate failure -----------------------+---------------------------------------------------- Reporter: eschnett | Owner: knarf Type: defect | Status: assigned Priority: blocker | Milestone: Component: Cactus | Version: Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by knarf):

* priority: major => blocker * component: EinsteinToolkit website => Cactus

Comment:

&%&^, I wanted to have that fixed by now. Well - the good news is that I have the new private .key file. The bad news is that the new .crt is still missing - pinging the relevant local people to send it to me...

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:16 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

5 Jan 5 Jan

5:34 p.m.

#1061: Certificate failure -----------------------+---------------------------------------------------- Reporter: eschnett | Owner: knarf Type: defect | Status: closed Priority: major | Milestone: Component: Cactus | Version: Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by knarf):

* priority: blocker => major * status: assigned => closed * resolution: => fixed

Comment:

New cert is installed. Please open a new ticket next time something is wrong with the certs.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1061#comment:17 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

5025

Age (days ago)

5156

Last active (days ago)

trac@lists.einsteintoolkit.org

17 comments

1 participants

tags (0)

participants (1)

Einstein Toolkit