Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?
Many people have decided to implement Let's Encrypt into their production sites. I find this still a very bad idea to be done without being very (but really very) careful. Let's Encrypt brings you freedom but also limits you in using the certificate with SHA-256 RSA Encryption. Support for SHA-2 has improved over the last few years. Most browsers, platforms, mail clients and mobile devices already support SHA-2. However, some older operating systems such as Windows XP pre-SP3 do not support SHA-2 encryption. Many organizations will be able to convert to SHA-2 without running into user experience issues, and many may want to encourage users running older, less secure systems to upgrade. In this tutorial, we are going to deal with this incompatibility in a simple, but still nasty way.
However, at this point there are several problems with DV certificates. The identity verification rules changed somewhere between 2012 and 2014. In 2012 you needed to control at least two pieces of information to obtain and use a legitimate 'trusted' certificate. These were usually:
The email address of the registered domain owner or a 'standard' domain email address.
Root access on a domain web server listed as an A or AAAA record.
However, in the newest CA guidelines, there is no requirement to check an email address to verify a domain. This means that a certificate can be both verified and used simply by demonstrating control over one small area of a domain. Of course, the removal of an interactive requirement makes the issuance of certs significantly less demanding on a domain owner... However, it also breaks the 'trust' within the DV certificate system.
In essence, as of the newest CA rules, a DV certificate has the same level of inherent trust as a self-signed certificate. This should be easy to see, because a self-signed certificate is generated and signed on the same server. Thus demonstrating control over the server at the A or AAAA record. It really doesn't matter if that certificate is then cross signed later, the chain of trust is still broken because the CA has been fooled into signing a fraudulent certificate. This 'tricking of CAs to issue certs' was a problem, but now it's actually written into the rules.
I really don't know why anyone would seek to muddy the 'trust' waters so much, but a fact's a fact, and the newest CA guidelines completely remove even the tiny bit of trust value in a DV certificate.
So, the next time you logon to your favorite on-line store and see the little green lock without the full green bar -- be sure to check the certificate... because if it's issued by "Let's Encrypt" or by Wosign or any CA that now issues DV certs to servers rather than domains, you really will have no ability to make sure that the certificate has not been issued to an intruder on the domain with unauthorized root access on that web server or maybe even a law enforcement office with unwarranted access.
EDIT***
Oh, I see now... the author of the article is setting up specific rewrite rules for specific user agents. That's a valid point, and I don't think the "Lets Encrypt" install script handles inserting those specific kinds of rewrite rules. However, most newly issued certs regardless of the vendor are going to have compatibility issues with older browsers due to newer browsers marking SHA1 certs as unsafe.
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
https://github.com/letsencrypt/letsencrypt
However, at this point there are several problems with DV certificates. The identity verification rules changed somewhere between 2012 and 2014. In 2012 you needed to control at least two pieces of information to obtain and use a legitimate 'trusted' certificate. These were usually:
- The email address of the registered domain owner or a 'standard' domain email address.
- Root access on a domain web server listed as an A or AAAA record.
However, in the newest CA guidelines, there is no requirement to check an email address to verify a domain. This means that a certificate can be both verified and used simply by demonstrating control over one small area of a domain. Of course, the removal of an interactive requirement makes the issuance of certs significantly less demanding on a domain owner... However, it also breaks the 'trust' within the DV certificate system.In essence, as of the newest CA rules, a DV certificate has the same level of inherent trust as a self-signed certificate. This should be easy to see, because a self-signed certificate is generated and signed on the same server. Thus demonstrating control over the server at the A or AAAA record. It really doesn't matter if that certificate is then cross signed later, the chain of trust is still broken because the CA has been fooled into signing a fraudulent certificate. This 'tricking of CAs to issue certs' was a problem, but now it's actually written into the rules.
I really don't know why anyone would seek to muddy the 'trust' waters so much, but a fact's a fact, and the newest CA guidelines completely remove even the tiny bit of trust value in a DV certificate.
So, the next time you logon to your favorite on-line store and see the little green lock without the full green bar -- be sure to check the certificate... because if it's issued by "Let's Encrypt" or by Wosign or any CA that now issues DV certs to servers rather than domains, you really will have no ability to make sure that the certificate has not been issued to an intruder on the domain with unauthorized root access on that web server or maybe even a law enforcement office with unwarranted access.
EDIT***
Oh, I see now... the author of the article is setting up specific rewrite rules for specific user agents. That's a valid point, and I don't think the "Lets Encrypt" install script handles inserting those specific kinds of rewrite rules. However, most newly issued certs regardless of the vendor are going to have compatibility issues with older browsers due to newer browsers marking SHA1 certs as unsafe.