https-Certificate issues

[christophknoth]

With the help of Helmut from the Mathematisches Forschungsinstitut Oberwolfach I installed an https-Certificate. So theoretically the platform is now reachable via https://imaginary.org/ But I guess we still have to do some adjustments on Drupal because there is still an error message in the browser. This is issue should help to identify the changes.

[christophknoth]

MathJax is not loaded via https and I just saw we still have google analytics code that we do not use. Or do we?

[elondaits]

OK. I'll look it up. There could be all sort of things...

[christophknoth]

When everything works we could think about forwarding all traffic to https?

[elondaits]

That's more or less the idea these days... in fact there's a program by some big companies (Google I think) that either this or next year (can't remember) will try to get every site on https by making it easier / cheaper (free?).

... However I think it will make the site slower... but at minimum non-anonymous users could be redirected to https on log-in and the others remain in http for a while.

[christophknoth]

This is a test for our ssl setup: https://www.ssllabs.com/ssltest/analyze.html?d=imaginary.org&hideResults=on&clearCache=on

We still had this SSL 3.0 vulnerability the so called Poodle bug that is why I disabled ssl 3.

[christophknoth]

Implementing Perfect Forward Secrecy would be ideal.

[helmut2]

Dear all,

upon Christian's suggestion I will post a rough translation of the problem analysis done by our certificate provider DFN-PKI:

A look at https://www.ssllabs.com/ssltest/analyze.html?d=imaginary.org&hideResults=on&clearCache=on reveals, that the CA chain is missing, that must be delivered by the web server in order to let the Java RTE successfully validate the server certificate.

The HTTP server configuration has some more considerable weak points ...

A correct configuration of the CA chain does not suffice for Java 6 to work, as Java 6 does not support Server Name Identification (SNI).

Presently the server certificate of the DFN-PKI enters the web server configuration as a Name-Based Virtual Server. That means, the FQDN imaginary imaginary.org has not been assigned an IP address in the server configuration.

The SSL/TLS protocol without SNI first turns the FQDN (which is imaginary.org) into an IP addres (which is 185.2.100.129), and then connects to the IP address. Therefore Java will see the certificate configured for the IP address, namely

depth=0 CN = vmd3220.contabo.net verify error:num=18:self signed certificate verify return:1 depth=0 CN = vmd3220.contabo.net verify return:1 Certificate chain 0 s:/CN=vmd3220.contabo.net i:/CN=vmd3220.contabo.net -----BEGIN CERTIFICATE----- MIICuDCCAaACCQClxDF4wCfURjANBgkqhkiG9w0BAQUFADAeMRwwGgYDVQQDExN2 [...] Lu3fa14K12ASusNgHUzILkF7F65rcDLx4800uA== -----END CERTIFICATE----- Server certificate subject=/CN=vmd3220.contabo.net issuer=/CN=vmd3220.contabo.net

which apparently is a self-signed certificate of your host provider.

To make sure the configuration works with Java 6, your virtual server must be configured to be an IP address based virtual server.

But Java 6 should not be used anymore anyway. With Java 7/8 repairing the CA chain should fix at least the first error.

You might look after the peculiarities with code signing afterwards. But let's do one step at a time ...

[elondaits]

I'll take a look at all of this and fix it soon.

[elondaits]

I've been working with this. I fixed the CA chain issue, implemented FS and got the site an A (from a B before). I tested many FS configurations and due to obsolete security options in old browsers and OSs there doesn't seem a perfect solution to all... the current cfg is from Qualys)

There still is an issue when accessing https://www.imaginary.org ... the htaccess file should redirect to https://imaginary.org but I THINK that the browser is checking the certificate and showing a warning before doing the redirect (which sounds about right).

As I understand it (and I don't understand much about this subject anyway) the certificate could / should specify what domain prefixes it's valid for. If so, we'd need a new certificate that allows the optional www, even if we'll redirect away from it later. In fact, we should think forward and get a certificate that supports our other subdomains (staging as a bare minimum, but preferably the subsites, dev servers, etc.) ... I'm not sure of all the repercussions but a wildcard certificate would be useful if possible.

[helmut2]

Dear Eric, the policy of our certificate issuer DFN PKI does not allow wildcard names like *.imaginary.org. Please send me a list of aliases (i.e. further dns names like www.imaginary.org, ...), so I can generate a new server certificate for imaginary.org that incorporates these aliases. If your list contains more than a few items, please indicate their priority, as I am not sure about the maximal number of aliases.

[elondaits]

Please @christophknoth check this list and put the "Unknown" subdomains under either "High priority" or "Desirable"... I'm not sure about them. Consider that although they are different priority every web site should work under https even if they don't show sensible data since otherwise malicious content can be injected to them in unsafe networks (unsafe networks = any public Wi Fi, for starters).

High Priority

• www
• staging

Desirable

• dev_ck
• dev_eric
• dev_kr

Unknown

• 2048
• analytics
• cloud
• concurso2015
• formula
• math-communication-network
• monitoring
• uruguay
• workplan

[christophknoth]

High Priority

2048 analytics formula cloud math-communication-network (we load this as an iframe on the imaginary site) monitoring

[HexeBianca]

workplan brauchen wir auch.

[christophknoth]

@HexeBianca workplan is needed as a link, but is only an iframe the redirects to a google word document, so it does not need https as google offers it

[HexeBianca]

ah, ok, sorry.

[christophknoth]

https is needed for everything where people log in and/or transfer content that could be privacy related or where we might do something like that in the future

[helmut2]

Generating the certificate failed, as the underscore (_) is not a valid character in host names, cf. http://en.wikipedia.org/wiki/Hostname. I suggest to take dev-ck, dev-eric, and dev-kr instead of dev_ck, dev_eric, and dev_kr, resp.. The alternative would be not to include the dev... names in the certificate at all.

[elondaits]

They're not as high priority as the others, but in the interest of security they should be encrypted as well... also because being the dev servers it's useful to test that the integration of https works OK. I'll try to change the names today and let you know. If not I'll see about migrating them to a new name.

[elondaits]

@helmut2 , I renamed the dev domains so now the list would be

High Priority

• www
• staging
• 2048
• analytics
• formula
• cloud
• math-communication-network
• monitoring

VERY Desirable

• dev-ck
• dev-eric
• dev-kr

Desirable

• concurso2015
• uruguay
• workplan

[elondaits]

The new certificates @helmut2 sent me are installed across all the subdomains listed in my previous comment and they're working OK.

... The next step I'll take is scan the site for content included through http and change that to match the protocol used to access the site (links of the form "//imaginary.org/page/" are connected either through http or https depending on how the site was accessed).

[elondaits]

Since the move to https requires all type of changes, fixes and configurations I created a milestone to encompass all individual issues. I'm closing this issue because the original issues with the certificate appear to be fixed.