Recently it is exposed that WoSign, a Chinese Certificate Authority (CA), secretly purchased StartCom, the CA currently signing all certificates of KDE.org. The related news and comments are linked here: https://news.ycombinator.com/item?id=12411870 Both WoSign and StartCom have been reported on their loose verification and issuing practices, often violating their own ToS and basic CA requirements. They are not worth trusting. I have chosen to disable their root certificates in all my browsers, and I advise everyone seeing this to do the same. It is for the better to transition from it and to Let's Encrypt, an open, free and automated CA. The documentation of Let's Encrypt is linked here: https://letsencrypt.org/docs/ I have no affiliation with WoSign, StartCom, or Let's Encrypt. Reproducible: Always Steps to Reproduce: 1. Access the url provided 2. View the certificate of server Actual Results: Issuer field of the certificate is: CN = StartCom Class 2 Primary Intermediate Server CA OU = Secure Digital Certificate Signing O = StartCom Ltd. C = IL Expected Results: Issuer field of the certificate should be: CN = Let's Encrypt Authority X3 O = Let's Encrypt C = US
Let's Encrypt is not suitable for use with KDE Infrastructure.
(In reply to Ben Cooksley from comment #1) > Let's Encrypt is not suitable for use with KDE Infrastructure. Care for a bit more explanation?
We have systems which run on multiple servers, while Lets Encrypt relies on being able to fetch a value from your server over HTTP. Therefore only one machine will get the request and the certificate. Additionally, we have non-HTTP based servers which need SSL, and the way our DNS system is setup doesn't allow automated changes to it (for security reasons among others). Plus we have dozens and dozens of subdomains across just kde.org, which is why we rely on wildcard certificates.
IMO an automated PKI is better than a manual wildcard certificate in the long run. I am confused by "systems which run on multiple servers". Are you trying to say that you need certs on machines without a public IP? If at the same time you prohibit DNS change, then that would indeed leave those machines without cert. Non-HTTP is not a concern, since ACME client itself speaks HTTP.
https://coolaj86.com/articles/lets-encrypt-with-haproxy/ Linked is an article describing process of DVSNI challenge via HAProxy. It is all on local machine in the article but I imagine it can also be used for internal machines.
We're not going to throw our entire server infrastructure out of the window and start afresh simply to accomodate a new CA. I've tried to implement LetsEncrypt on our servers in the past (we've had this discussion internally way before you thought you'd file a bug and we've actually tried testing it on live systems) but the effort just isn't worth it. Maybe as we move to immutable infrastructure in the future we will revisit this topic of contention, but right now there are more pressing tasks that need to be taken care of.
I understand that this is not a priority. With the high profile launch of Let's Encrypt I imagined that you would have internally considered it. This bug is less an advocate for Let's Encrypt but more a warning against StartCom. IMO Let's Encrypt is not "simply" a new CA, but I concede that it's a decision of yours.
https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview > Taking into account all the issues listed above, Mozilla’s CA team has lost confidence in the ability of WoSign/StartCom to faithfully and competently discharge the functions of a CA. Therefore we propose that, starting on a date to be determined in the near future, Mozilla products will no longer trust newly-issued certificates issued by either of these two CA brands. > We plan to distrust only newly-issued certificates to try and reduce the impact on web users, as both of these CA brands have substantial outstanding certificate corpuses. Our proposal is that we determine “newly issued” by examining the notBefore date in the certificates. It is true that this date is chosen by the CA and therefore WoSign/StartCom could back-date certificates to get around this restriction. And there is, as we have explained, evidence that they have done this in the past. However, many eyes are on the Web PKI and if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots. Mozilla has decided to not trust StartCom anymore. Although KDE is fine for now, the current StartCom certificate will expire in less than a year, before StartCom can start the readmission process. I still believe using Let's Encrypt, even though involving re-architecture, is a better move long-term. Anyway, your choice.
We've seen that document are are currently evaluating alternatives. While LE remains unsuitable for our infrastructure, we are considering other traditional CAs who can offer us affordable certificates for our needs.
We've arranged for replacement certificates and will be rolling these out over the next few days, which resolves this.