Ticket #165 (closed defect: invalid)

Opened 6 years ago

Last modified 6 years ago

Security certificate warning on new server

Reported by: ed Owned by: chris
Priority: critical Milestone:
Component: Live server Keywords:
Cc: Estimated Number of Hours: 0.0
Add Hours to Ticket: 0 Billable?: yes
Total Hours: 3.0

Description

Users are getting site untrusted warnings: is all well with the security certificate on new servers?

"Just one comment - when I try to connect to the login page, my browser
is telling me that the site is untrusted and that the connection can not
be verified. Are there some additional steps you need to take to ensure
that the site connects securely?

The browser reports that your site is using an invalid security certificate."

Change History

comment:1 Changed 6 years ago by ed

  • Component changed from Drupal modules & settings to Live server

here's another enquiry:

...When I try to register with your website I get the following warnings, which
I think understandably, makes me wary of proceding any further:

This Connection is Untrusted

You have asked Firefox to connect
securely to www.transitionnetwork.org, but we can't confirm that your
connection is secure.

Normally, when you try to connect securely,
sites will present trusted identification to prove that you are
going to the right place. However, this site's identity can't be verified.

What Should I Do?

If you usually connect to

comment:2 Changed 6 years ago by chris

  • Add Hours to Ticket changed from 0.0 to 0.5
  • Total Hours changed from 0.0 to 0.5

That's odd, I've created a wiki page which you could point people with this problem to and ask them to follow the suggestions on it.

http://wiki.transitionnetwork.org/Security

comment:3 Changed 6 years ago by ed

OK - these have only begun to appear since the move - is there anything that might have changed? Just checking...

comment:4 Changed 6 years ago by chris

Well, it's a Debian rather than a FreeBSD Apache and the layout of the config files is very different, but the directives should be more-or-less the same.

I'm not sure what is causing this problem, some more feedback from the users after they have tried the suggestions on the http://wiki.transitionnetwork.org/Security wiki page would be good to have.

comment:5 Changed 6 years ago by ed

will do...

comment:6 Changed 6 years ago by chris

  • Add Hours to Ticket changed from 0.0 to 2.5
  • Total Hours changed from 0.5 to 3.0

I have gone over all the SSL settings again and there was one missing compared to on gaia, SSLCACertificateFile and the gandi.net documentation suggests it should be used, but it's for client certificates, something we are not using, so I think perhaps their documentation is at fault and the directive that might help is instead is the SSLCertificateChainFile directive so this has been added (see wiki:NewLiveServer#apache) and it points to the whole chain of certs (all in one gandi.pem file).

This difference this seems to make is, where as the wiki:SecurityInfo#ChecktheSSLcertonthecommandline had this chain for the gaia server:

Certificate chain
 0 s:/OU=Domain Control Validated/OU=Gandi Standard Wildcard SSL/CN=*.transitionnetwork.org
   i:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
 1 s:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
   i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware

We now have:

Certificate chain
 0 s:/OU=Domain Control Validated/OU=Gandi Standard Wildcard SSL/CN=*.transitionnetwork.org
   i:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
 1 s:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
   i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
 2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

The only other difference with the FreeBSD settings is that on the old server the allowed ciphers was different:

SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:+EXP:+eNULL:+SSLv3:+TLSv1

Where as the new server has the Debian defaults:

SSLCipherSuite HIGH
SSLProtocol all -SSLv2

If users still have a problem I could try the previous setting to see if this is the cause of the problem, but I don't think there is much real difference here.

comment:7 Changed 6 years ago by chris

Or it could simply be because the users have the wrong date on their computer and it thinks that either the cert is only valid in the future (say if their clock is set to 2000) or in the past (say if their clock is set to 2020), see this and this.

I suspect this might be the answer after all that! D'oh!

comment:8 Changed 6 years ago by chris

  • Status changed from new to closed
  • Resolution set to invalid

I think this is closed unless someone with the right date on their computer and also with the Gandi root certificate installed has a problem.

comment:9 Changed 6 years ago by ed

yup - i'm awaiting replies from the punters...

Note: See TracTickets for help on using tickets.