Project

General

Profile

Issue #1335

Problem with SSL on website

Added by Michel Le Bihan about 5 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
High
Category:
Infrastructure (web, git)
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed
Device:
Grant:

Description

When visiting the website I'm getting this error:
redmine.replicant.us uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. (Error code: sec_error_unknown_issuer)
I know I can add an exeption but it's a bit unsafe...


Related issues

Related to Replicant - Issue #1323: Switch all Replicant URL references to httpsClosedWolfgang Wiedmeyer09/02/2015

Actions
#2

Updated by My Self about 5 years ago

I would say, as you wrote: "An additional root certificate may need to be imported."

Just go here: http://www.cacert.org/index.php?id=3
grab this CAcert root certificate: Class 3 PKI Key > Intermediate Certificate (PEM Format) and import it to your browser.
Depending on operating system- and browser there are different ways to do that; but I'm sure the search engine of you choice will find every combination シ

#3

Updated by Michel Le Bihan about 5 years ago

http://www.startssl.com/ is also issuing free SSL certifiates and there are included in almost all browsers.

#4

Updated by Paul Kocialkowski about 5 years ago

  • Status changed from New to Rejected
  • Resolution set to invalid

Well, I'm fine with CaCert which is currently the only community CA. We've already had this discussion in the past, please open a discussion (not a bug report) if you have something new to contribute to it.

#5

Updated by Michel Le Bihan about 5 years ago

I can't find this discussion. Could you please link it to me?

#6

Updated by My Self almost 5 years ago

I can't find this discussion. Could you please link it to me?

I think this thread is what Paul means: http://redmine.replicant.us/boards/33/topics/5199?r=5889#message-5889

#7

Updated by Kurtis Hanna over 3 years ago

  • Assignee changed from Paul Kocialkowski to Wolfgang Wiedmeyer

If this project wants to use CA Cert, it still needs to be updated to get an A rating from the definitive 3rd party auditing website.

https://www.ssllabs.com/ssltest/analyze.html?d=redmine.replicant.us

It currently gets a C, which is pretty horrible.

#8

Updated by Kurtis Hanna over 3 years ago

great news! I spoke with Ramereth from the #OSUOSL freenode room and they started fixing our TLS cyphers so that we now get an A rating at ssllabs for some of our subdomains. I think that blog.replicant.us and redmine.replicant.us are both now getting B ratings instead of C ratings. This is a good start!

Ramereth said the following:

"we probably should look at moving blog.replicant.us to one of our new hosts soon. it would be more work to get that rating higher due to the machine it's on."

"we support any cert that works with apache. we just need a key and cert. just send us a ticket to do it. Let's encrypt is more complicated as we need to work out the automation part and how it interacts with our systems. but we're working on resolving that in the next few months, hopefully by summer if not sooner. I mean, we can install the cert, but we'd have to change it every 90 days.. just send an email to with the details. we'll likely want to find a way to copy the private key securely and not via email."

So, are we in agreement that we should move away from CACert and get one cert that includes all our subdomains? If so, I think Let's Encrypt and https://www.globalsign.com/en/ssl/ssl-open-source/ are two good free options. What are all the subdomains that we have right now? Here's my best guess of an exhaustive list:

redmine.replicant.us
blog.replicant.us
www.replicant.us

git.replicant.us already has an A+ rating, probably thanks to Wolfgang, so I'm assuming we can leave that one be.

If we go this route, are we also in agreement that we should ask that all of our http traffic get redirected to https?

Wolfgang: If you agree to moving forward with a non-CACert cert, do you want to make it or would you rather I do it? I've done this a few times before and think I can make it happen.

#9

Updated by Jeremy Rand over 3 years ago

Kurtis Hanna wrote:

So, are we in agreement that we should move away from CACert and get one cert that includes all our subdomains? If so, I think Let's Encrypt and https://www.globalsign.com/en/ssl/ssl-open-source/ are two good free options.

I definitely support doing this. While Let's Encrypt is great, the 90-day expiration period makes it basically unusable unless OSUOSL installs the automation software. Since it sounds like OSUOSL can't do that immediately, I'd suggest going with GlobalSign -- I've had brief interaction with their customer service and they're very helpful, flexible, and responsive. After the GlobalSign cert eventually expires, re-evaluating whether to move to Let's Encrypt at that point may be a good idea.

What are all the subdomains that we have right now? Here's my best guess of an exhaustive list

The following Startpage query suggests that the 4 subdomains you list are the only ones in service:

replicant -"powered by redmine" -"Proudly powered by free software: PHP, Bootstrap, SimplePie, Lightbox" -"Proudly powered by WordPress" -"GitLab" site:replicant.us

If we go this route, are we also in agreement that we should ask that all of our http traffic get redirected to https?

My inclination would be to wait a month or so to verify that HTTPS is working properly, then start redirecting HTTP to HTTPS, then if everything is still working properly after another month, add HSTS.

As a side note: SSL Labs is a great tool, but it's not the only one out there. I'm quite fond of Mozilla Observatory, which can also detect security-relevant misconfigurations in the HTTP headers in addition to the TLS implementation. Once Replicant is passing SSL Labs with flying colors, you might consider starting to address the issues raised in Mozilla Observatory.

Great to see that this is getting attention. Cheers!

#10

Updated by Jeremy Rand over 3 years ago

Relatedly, quoting myself on IRC on Feb 22 2017:

if it helps with the certificate issues, there's a good chance that I'm okay with donating circa 20 USD (in Bitcoin) to the Replicant project, contingent on the website moving to Let's Encrypt.

That bounty still stands, and I also extend the bounty to cover a GlobalSign Open-Source cert given that it looks like waiting for Let's Encrypt would delay things.

#11

Updated by Wolfgang Wiedmeyer over 3 years ago

  • Status changed from Rejected to New
  • Assignee changed from Wolfgang Wiedmeyer to Paul Kocialkowski
  • Resolution deleted (invalid)

Reopening because I agree that this needs to be fixed. Properly verifying the CAcert root cert is not that easy and considering the complaints from some users over the last months, this causes frustration and confusion as well. The redmine instance should have priority as we are handling user data here.

Thank you for working on this with OSUOSL! Over a month ago, I only asked them about moving to Let's Encrypt. The response was more or less the same as above, only that I was additionally assured that Replicant was added to the list of projects that want to get Let's Encrypt.

Regarding the domains, there is also the mailing list at lists.osuosl.org and the ftp server at ftp-osl.osuosl.org that has all the Replicant binaries. The ftp server only has a B rating because of enabled RC4 ciphers. I guess that this was done intentionally for backwards compatibility and I don't see this as a big issue. The mailing list however has a B rating because of issues with the key exchange, same as with the redmine instance. It would be good to get his fixed.

I set up Let's Encrypt some time ago on the git server so this part is fixed (see #1599).

There are now two options to get this issue fixed asap for redmine, website and blog without having to wait for OSUOSL to implement Let's Encrypt:
  1. Move them to a different host where full shell access is possible and we can configure everything with Let's Encrypt
  2. Get a trusted cert

I prefer the first option as this would also make it possible to update the Redmine installation. Paul and Denis had this planned for some time but I don't know about a timeframe. I'm at disposal for any help in this regard.
Paul has some limited shell access at OSUOSL, but he might not be able to export the database. So OSUOSL probably needs to be asked for a database dump and an archive of all the attachments. There might be other data that is needed.
Redirecting all http requests to https can then be done easily when we have access to the webserver config.

The second option could be the fastest solution for now, but not be necessary if we can do the first one asap. I have to assign back to Paul because I don't have access to a @replicant.us address and this is probably needed for verification of the cert. Also Paul needs to check what he can do with his shell access at OSUOSL for option 1.
I don't like the requirements for the free cert at GlobalSign, especially the non-commercial clause as this is always open for interpretation. I consider paying for a cert extortion in most cases (at least in the past) and I wouldn't like to see Replicant funds used for this.

#12

Updated by Wolfgang Wiedmeyer over 3 years ago

There is another problem with the CAcert certificate. It appears that the root cert is signed using MD5 as signature algorithm. Firefox shows the following error message:

The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure.
Error code: SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED

Generating a new CAcert wildcard certificate for replicant.us likely solves this problem, but I don't think it's worth it spending time on this. We should look to get better options working.

Jeremy, thanks for the bounty offer!

#13

Updated by Kurtis Hanna over 3 years ago

OSUOSL is able to use letsencrypt right now. they just don't have their renewal automation set up, and would have to renew the cert after 90 days. they are saying that they plan on getting automatical renewal of letsencrypt certs working within a few months, which would be before our first required renewal.

are you able to expand the git.replicant.us cert to include 'www.' 'redmine.' and 'blog.' and plain ol' replicant.us and then send the new cert to ?

i messaged Paul and Ramereth on IRC earlier today but haven't heard back from either of them yet. i think that migrating to a new host is a seperate issue, expecially if you are able to expand the letsencrypt git.replicant cert to include all the other subdomains and replicant.us right now.

#14

Updated by Kurtis Hanna over 3 years ago

what do you think about this as a short term option? https://www.godaddy.com/ssl/ssl-open-source.aspx

It doesn't seem to have any strings attached. I agree that the globalsign requirement that it is "Not be a site that is also used for commercial purposes" could be problematic.

#15

Updated by Wolfgang Wiedmeyer over 3 years ago

Kurtis Hanna wrote:

are you able to expand the git.replicant.us cert to include 'www.' 'redmine.' and 'blog.' and plain ol' replicant.us and then send the new cert to ?

i messaged Paul and Ramereth on IRC earlier today but haven't heard back from either of them yet. i think that migrating to a new host is a seperate issue, expecially if you are able to expand the letsencrypt git.replicant cert to include all the other subdomains and replicant.us right now.

No, I don't think that I'm able to do this. You need to prove ownership of the domain in some way and in the case of Let's Encrypt, this is difficult or even impossible with our current setup. I can't simply request a cert for other subdomains from a host that only serves one subdomain.

what do you think about this as a short term option? https://www.godaddy.com/ssl/ssl-open-source.aspx

Looks good. Do you know if such a cert can cover multiple subdomains or if it can be a wildcard cert?

#16

Updated by Jeremy Rand over 3 years ago

Wolfgang Wiedmeyer wrote:

I don't like the requirements for the free cert at GlobalSign, especially the non-commercial clause as this is always open for interpretation.

I had an email exchange with GlobalSign in 2015 about this (in the context of getting a cert for https://www.namecoin.org/ ). Here's what Gregory Tomko from GlobalSign told me at the time:

Just double checked with my manager and yeah you guys should be approved for a free cert. Basically as long as you're not selling the software, it's all good. It's fine for financial transactions to be involved (cryptocurrency or otherwise) as long as it's not for purchase of the software itself.

I don't know whether that's still their current policy, but anyway I hope this info helps inform the decision-making process.

Cheers!

#17

Updated by Jeremy Rand over 3 years ago

Kurtis Hanna wrote:

what do you think about this as a short term option? https://www.godaddy.com/ssl/ssl-open-source.aspx

It doesn't seem to have any strings attached.

It looks like that offer is only valid for the first year, which to my knowledge is not the case for GlobalSign. It sounds like Replicant is planning to switch to Let's Encrypt within a year anyway, so this might not be a problem -- but it definitely does qualify as a "string attached" that should be considered.

#18

Updated by Kurtis Hanna over 3 years ago

I just checked with OSUOSL and they are ready to update redmine for us! We just need to change a DNS setting, which I hope happens in the next few days. After speaking with Paul, it sounds like a migration off of OSUOSL might take a little while.

So, I propose we get a new cert. I personally don't have a preference where we get it from. Wolfgang, do you prefer GoDaddy, GlobalSign, or some other option like https://www.sslforfree.com/ ? Would you like Jeremy to email GlobalSign again and request that they give Replicant an official green light, in the same way as they did with NameCoin?

I tried calling GoDaddy to ask if they support multiple sites. Their wait time was too long for me to be able to get through. I'll try again.

https://www.sslforfree.com is something I randomly found during an internet search. I don't know how reputable they are, but they do support multiple domains. Maybe there are other options like this one out there.

#19

Updated by Jeremy Rand over 3 years ago

Wolfgang Wiedmeyer wrote:

The ftp server only has a B rating because of enabled RC4 ciphers. I guess that this was done intentionally for backwards compatibility and I don't see this as a big issue.

FYI, ciphersuite downgrade attacks are a thing (there have been some high-profile attacks discovered recently), so unless there is a very strong reason why RC4 needs to be supported, I would recommend disabling the RC4 ciphersuites.

Cheers!

#20

Updated by Jeremy Rand over 3 years ago

Kurtis Hanna wrote:

https://www.sslforfree.com is something I randomly found during an internet search. I don't know how reputable they are, but they do support multiple domains. Maybe there are other options like this one out there.

I recommend staying away from this. A quick Startpage search turned up this thread: https://community.letsencrypt.org/t/easiest-way-to-use-lets-encrypt/7633 . In which the main developer admits that his website has access to your private key, but he promises not to abuse that privilege. Dangerous as hell.

EDIT: Not only does he admit that he has access to your private key, he doesn't seem to think this is a big deal, which raises severe concerns about his competence to be handling anything related to TLS.

#21

Updated by Wolfgang Wiedmeyer over 3 years ago

Jeremy Rand wrote:

Wolfgang Wiedmeyer wrote:

The ftp server only has a B rating because of enabled RC4 ciphers. I guess that this was done intentionally for backwards compatibility and I don't see this as a big issue.

FYI, ciphersuite downgrade attacks are a thing (there have been some high-profile attacks discovered recently), so unless there is a very strong reason why RC4 needs to be supported, I would recommend disabling the RC4 ciphersuites.

Yes, they are, but the downgrade attacks need to be prevented on the client side, anyway. That's why I don't see it as a big issue.

#22

Updated by Wolfgang Wiedmeyer over 3 years ago

Kurtis Hanna wrote:

I just checked with OSUOSL and they are ready to update redmine for us! We just need to change a DNS setting, which I hope happens in the next few days. After speaking with Paul, it sounds like a migration off of OSUOSL might take a little while.

Ok, are Paul and Denis aware of the needed DNS change? I hope there is not much downtime and the upgrade works without issues.

So, I propose we get a new cert. I personally don't have a preference where we get it from. Wolfgang, do you prefer GoDaddy, GlobalSign, or some other option like https://www.sslforfree.com/ ? Would you like Jeremy to email GlobalSign again and request that they give Replicant an official green light, in the same way as they did with NameCoin?

I agree with Jeremy regarding sslforfree. And they use ACME, just like every Let's Encrypt client, so from my understanding, there is nothing they can do we can't do ourselves.
I'd prefer GoDaddy, given that we get a cert that is valid for all needed domains. I guess multiple certs (one for each domain) would be fine, too. If we can only get one cert for one domain, I'd still consider it and then use it for the Redmine instance. I also think that the one year limit is no issue. Either OSUOSL should have full support for Let's Encrypt by then or we should be able to move away from OSUOSL until then.

I'm still not sure about GlobalSign. I just find it ridiculous to get a distribution restriction indirectly imposed by the certificate authority. Even if it may never affect us, they still could pull the cert at any point, e.g. just because they don't like that we recommend Tehnoetic on the website. Jeremy, feel free to contact them about this, but I'd also like to hear Paul's and Denis' opinion on this.

I just checked and Replicant's DNS is handled by Gandi. They have SSL certificate offers for domain registrations: https://www.gandi.net/ssl
It looks like we are not eligible for a free cert, but afair Debian had certs from them in the past before they switched to Let's Encrypt. Maybe they are willing to provide a free cert for a free software project like Replicant.

Thank you guys for working on this!

#23

Updated by Wolfgang Wiedmeyer over 3 years ago

There is also the issue that http is not redirected to https on the mailing list host at lists.osuosl.org, so passwords and other personal data can be intercepted in the online forms. Kurtis already mentioned this in the Redmine upgrade ticket, but it may be necessary to open a separate ticket about this.
I just add this as a reminder, in case we need to act on this again.

#24

Updated by Jeremy Rand over 3 years ago

Wolfgang Wiedmeyer wrote:

Jeremy Rand wrote:

Wolfgang Wiedmeyer wrote:

The ftp server only has a B rating because of enabled RC4 ciphers. I guess that this was done intentionally for backwards compatibility and I don't see this as a big issue.

FYI, ciphersuite downgrade attacks are a thing (there have been some high-profile attacks discovered recently), so unless there is a very strong reason why RC4 needs to be supported, I would recommend disabling the RC4 ciphersuites.

Yes, they are, but the downgrade attacks need to be prevented on the client side, anyway. That's why I don't see it as a big issue.

My understanding is that usually TLS downgrade attacks can be prevented if either the client or the server doesn't support the insecure ciphersuite, but there are weird cases where only the server can prevent the downgrade. Logjam is an example of this, see https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf . Given these issues, unless there is a specific reason why RC4 is needed (it sounds like there isn't), I still strongly recommend disabling the RC4 ciphersuites server-side.

#25

Updated by Jeremy Rand over 3 years ago

Wolfgang Wiedmeyer wrote:

I'm still not sure about GlobalSign. I just find it ridiculous to get a distribution restriction indirectly imposed by the certificate authority. Even if it may never affect us, they still could pull the cert at any point, e.g. just because they don't like that we recommend Tehnoetic on the website. Jeremy, feel free to contact them about this, but I'd also like to hear Paul's and Denis' opinion on this.

I've contacted GlobalSign, and everything sounds good pending a reply from Pedro. @Kurtis/Wolfgang, have you received any confirmation from Pedro at GlobalSign? (I haven't seen any emails on that thread since the April 7 emails from Greg.)

#26

Updated by Wolfgang Wiedmeyer over 3 years ago

Jeremy Rand wrote:

My understanding is that usually TLS downgrade attacks can be prevented if either the client or the server doesn't support the insecure ciphersuite, but there are weird cases where only the server can prevent the downgrade. Logjam is an example of this, see https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf . Given these issues, unless there is a specific reason why RC4 is needed (it sounds like there isn't), I still strongly recommend disabling the RC4 ciphersuites server-side.

Agreed. It's a non-issue when it's fixed on the client, but if it isn't, it would indeed be good to have this fixed on the server. It's not fixed for Replicant 4.2 users as the patches I submitted for fixing this were never part of images. So yes, this should definitely be part of a ticket about the ssl server config. GlobalSign lists having an A rating as a requirement for the cert, so we may be required to get this fixed anyway.

I also didn't yet get a mail from Pedro.

#27

Updated by Wolfgang Wiedmeyer over 3 years ago

  • Assignee changed from Paul Kocialkowski to Wolfgang Wiedmeyer
#28

Updated by Wolfgang Wiedmeyer over 3 years ago

The GlobalSign cert is now in place for redmine, blog and website. The redirect is still missing. This is somewhat tracked in #1323.
It would be nice to additionally have HSTS, at least for redmine.

#29

Updated by Kurtis Hanna over 3 years ago

I am willing to communicate to OSUOSL about HSTS, but I'm not very familiar with this and am not sure what to ask them. Please feel free to either contact them yourselves, or let me know what to ask and I'll contact them about this.

On a related note, would we need to ask Denis or Paul to modify the CAA DNS record? I'm also not super familiar with this and don't know what to ask them.

#30

Updated by Jeremy Rand over 3 years ago

Kurtis Hanna wrote:

I am willing to communicate to OSUOSL about HSTS, but I'm not very familiar with this and am not sure what to ask them. Please feel free to either contact them yourselves, or let me know what to ask and I'll contact them about this.

The issue with HSTS is that once HSTS is enabled, if Replicant's TLS certificate gets revoked or expired, the affected Replicant website domains will be inaccessible (you won't even be able to click through a warning to access the site) until the HSTS header expires or a new certificate is put in place. That new certificate would need to be trusted by browsers, so CACert or self-signed aren't an option. So, in practice, this means that we need to do one of the following (in descending order of security):

  1. Be willing to purchase a commercial CA-issued certificate in the event that GlobalSign's cert is revoked or expires.
  2. Use HSTS with a sufficiently short expiration period that the downtime caused by a hypothetical revocation or expiration of the GlobalSign cert would be considered acceptable.
  3. Wait for OSUOSL to support Let's Encrypt, so that we can switch to Let's Encrypt in the event that GlobalSign's cert is revoked or expires.

I think it's unlikely that GlobalSign's cert will be revoked or be banned from renewal, but it's important to consider the ramifications of such an event (despite it being unlikely).

So, the questions are: is the Replicant project willing to commit to buying a commercial CA-issued cert if that happens, and if not, how much downtime is "acceptable" if that event happens? The recommended expiration period for HSTS (if high security is desired) is 2 years, which obviously is not acceptable downtime if the cert goes bad. Obviously any expiration period for HSTS is more secure than the status quo (0 seconds), but committing to buying a cert in that event will enable you to have much better security than if you choose a short expiration period.

Let me know what you guys want to do, and I can then tell you what to ask OSUOSL for.

On a related note, would we need to ask Denis or Paul to modify the CAA DNS record? I'm also not super familiar with this and don't know what to ask them.

In my opinion, CAA is less important than HSTS, so if the same people would need to be involved in both tasks, let's worry about HSTS first. If we can parallelize them, let me know and I'll look into CAA.

Cheers!

#31

Updated by Wolfgang Wiedmeyer over 3 years ago

Just last weekend, I had an issue with HSTS on the Replicant Git host. The Let's Encrypt update didn't work because I had misconfigured Gitlab (the config only accepts one custom Nginx config change and not several). So the cert had expired and HSTS prevented connecting to the server which made fixing the issue a little harder.

Unexpected things can happen and in this case, the consequences would be quite fatal if a lot of users cannot access Replicant's websites anymore. So I tend to not add HSTS for now until the situation is more clear. If OSUOSL has Let's Encrypt available, we can ask them to enable HSTS in the process of switching to Let's Encrypt. Otherwise, max-age could be set for a period that expires when the current cert expires, but I don't think this is worth the risk.

#32

Updated by Jeremy Rand over 3 years ago

Jeremy Rand wrote:

Relatedly, quoting myself on IRC on Feb 22 2017:

if it helps with the certificate issues, there's a good chance that I'm okay with donating circa 20 USD (in Bitcoin) to the Replicant project, contingent on the website moving to Let's Encrypt.

That bounty still stands, and I also extend the bounty to cover a GlobalSign Open-Source cert given that it looks like waiting for Let's Encrypt would delay things.

Bounty sent.

#33

Updated by Wolfgang Wiedmeyer over 3 years ago

Should we keep this open? The originally reported issue is now solved and the issue is already quite crowded. If you want track SSL-related issues with the Replicant infrastructure, opening a new issue for them probably makes more sense.

#34

Updated by Jeremy Rand about 3 years ago

Wolfgang Wiedmeyer wrote:

Should we keep this open? The originally reported issue is now solved and the issue is already quite crowded. If you want track SSL-related issues with the Replicant infrastructure, opening a new issue for them probably makes more sense.

I agree. I suggest closing this issue and creating new issues for HSTS and CAA.

#35

Updated by Wolfgang Wiedmeyer about 3 years ago

  • Status changed from New to Closed
  • Resolution set to fixed

Also available in: Atom PDF