Migrate to full HTTPS by default #1123

Closed
fvanderbiest opened this Issue Nov 16, 2015 · 12 comments

Projects

None yet

4 participants

@fvanderbiest
Member

With the advent of https://letsencrypt.org/ I see no reason to keep unsecured transfers to the browser by default.
Proposal: migrate everything to https by default, including the documentation.

@fvanderbiest fvanderbiest added this to the 15.12 milestone Nov 16, 2015
@landryb
Member
landryb commented Nov 17, 2015

so much +1, even if i hate the complexity nightmare of TLS :)

@fphg
Member
fphg commented Nov 17, 2015

You mean : sdi.georchestra.org ? Or geOrchestra instances ?

@fvanderbiest
Member

I mean: the geOrchestra install documentation + template configuration should target an HTTPS setup by default for 15.12. Having a mixed HTTP/HTTPS setup will still be possible, but will require more changes.

Side-effect: sdi.georchestra.org should also switch to https.

@fphg
Member
fphg commented Nov 19, 2015

Le 19/11/2015 09:39, François Van Der Biest a écrit :

I mean: the geOrchestra install documentation + template configuration
should target an HTTPS setup by default for 15.12. Having a mixed
HTTP/HTTPS setup will still be possible, but will require more
changes.

Side-effect: sdi.georchestra.org should also switch to https.

While I'm convinced of https interest, I still find it amazingly
difficult to (correctly) set up. The IDS may move to full encrypted
streams but what about the third party clients ? Do referers have to
switch ?


Reply to this email directly or view it on GitHub:
#1123 (comment)

Fabrice Phung

@fvanderbiest
Member

I'd say, it depends on the clients.
Some of them will follow the 302 redirection to https without raising an eyebrow, some probably won't...

@fvanderbiest fvanderbiest self-assigned this Jan 11, 2016
@fvanderbiest
Member

Done. There are probably minor squirks here and there, but we'll fix them as we go.

@fvanderbiest fvanderbiest added 3 - Done and removed 2 - Working labels Jan 12, 2016
@landryb
Member
landryb commented Jan 12, 2016

So i'm all for HTTPS & letsencrypt, but if i try to harvest https://sdi.georchestra.org/geonetwork/ from a standalone GN3 instance, when fetching sources it immediately fails with (request from the proxy):

Some unexpected error occurred. Error text was: Received fatal alert: handshake_failure

and the traceback in catalina.out

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
        at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1991)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1098)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:275)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:254)

Trying to work it around by importing LE's X1 root in the keystore:

wget https://letsencrypt.org/certs/letsencryptauthorityx1.der
keytool -importcert -alias letsencrypt -file letsencryptauthorityx1.der -keystore /path/to/keystore -storepass password -noprompt

But apparently that's not the right root/certificate to add to validate the chain.

@pmauduit
Member

FYI on debian distro, the default truststore is here: /etc/ssl/certs/java/cacerts, but you have some hooks that can be used, if you have the following packages installed: ca-certificates and ca-certificates-java.

You should be able to save the certificate under /usr/local/share/ca-certificates/ (with the .crt suffix, not PEM !), then launch the update-ca-certificates command as root.

That's theoric, unfortunately: even with every certificates from https://letsencrypt.org/certificates/ I was not able to have my JVM trust sdi.g.o:443

@landryb
Member
landryb commented Jan 12, 2016

I also tried with https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.der since that's supposed to be the cert from which LE's certs are signed, but that didnt help with the handshake issue. Same thing if i directly import the certificate from sdi.georchestra.org in the keystore, it still fails. SSHell.....

@pmauduit
Member

You can use the following Java class to test SSL remote services: https://gist.github.com/pmauduit/2efbb1a374cbbc4327ec

@fvanderbiest
Member

Related commit: 7d6956a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment