echo -e "ServerSignature Off\nServerTokens Prod" >> /etc/apache2/apache2.conf
/etc/init.d/apache2 restart
openssl req -new -nodes -keyout webappsec-test.info.key -out webappsec-test.info.csr -newkey rsa:2048
cat webappsec-test.info.csr
Register here:
Copy and paste csr...
cat Domain_cert.pem CA_root.pem
https://mozilla.github.io/server-side-tls/ssl-config-generat...
====>
A+ on
Now? What's so hard about that?
I guess if you're using EC2 and Ubuntu on your server... ehhh...
Lets Encrypt certs are equivalent to self-signed certs.
No hassle ==> broken shit.
If you cross sign a self-signed cert what do you get?
A Let's Encrypt Cert.
Domain Ownership is not the same as file ownership.
That not the point.
The cross signature is worthless if the signed cert beneath it is self-signed.
If Identrust cross signed self signed certs, the self signed cert would be trusted too... and it would "work" in all browsers...
Coly Tarry Frap Tarts! you're daft.
Here try this:
1. Setup a domain with an MX record that points off domain and a dmarc p=reject record...
2. Try to get a cert from any CA other than Lets Encrypt without answering any emails sent to the off domain MX.
...
Then... install Lets Encrypt... bam-o! Cert heaven!
It's self-gawd-damn-fing-signed.
IdenTrust signed Let's Encrypt's intermediate certificate[1] using their trusted root certificate. This intermediate certificate has the CA flag set, so other certificates signed by it are to be trusted too. Intermediate certificates are used by all CAs.
When you run the client on your server, the client submits a CSR to Let's Encrypt's CA server. Let's Encrypt will then verify domain ownership (via HTTP, TLS or DNS[2]). This is done in accordance with CA/B Baseline Requirements, and their practice doesn't differ from other CAs who also offer HTTP[3] or DNS verification. If ownership can be verified, Let's Encrypt will then sign your certificate using their trusted intermediate certificate and send it back to you. It is thus not self-signed, but signed by a trusted CA key.
[1]: https://crt.sh/?caid=7395
[2]: soon!
[3]: At least one other CA (WoSign) does this, there are probably others I'm not aware of.
I know exactly how CAs work. I've built several.
Wosign does not issue a cert without an email verification.
You can look on their website. There's a nice big box to enter an email address to verify your domain and get the free cert.
Sorry -- "Let's Encrypt" with file verification is not DV.
It's just not DV. Simple really...
And it's gonna break the web. Like netlify up there a few post... using rackspace and "Let's Encrypt". ehh. The first few months will probably be fine and then everything is gonna tank.
Until the smart realize that ACME is fine -- as long as you remove the "or file verification" text.
If you've been involved in a CA, then you should be familiar with the CAB forum baseline requirements for Verification Practices. https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf
> For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that[] the Applicant[] has control over the FQDN by: [...]
> 4. Communicating with the Domain’s administrator using an email address [...] ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ [...] followed by the Domain Name[];
> 6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN
> 7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.
The approach used by Let's Encrypt meets this standard (of which email is just one of several options), and the methods they use are just as secure as using email. They specifically offer approach 6. above, which they call Simple HTTP, as well as other approaches that comply with 7. as outlined in https://letsencrypt.github.io/acme-spec/#rfc.section.7 Involving email in the verification process makes certificate provisioning harder to automate and adds no additional security.
The file contains a random token. This is essentially the same solution Let's Encrypt offers (among others).
DV certs make no promises about the identity of the site operator, just that communications are encrypted. I remember a decade ago buying certificates from Thawte required faxing them business records and ensuring that the D&B records matched the domain registration - while paying $450/year for a cert for a single hostname. The process was through, but wholly unnecessary for the vast majority of sites that weren't directly taking payment information.
Our intermediate is signed by ISRG Root X1. However, since we are a very new certificate authority, ISRG Root X1 is not yet trusted in most browsers. In order to be broadly trusted right away, our intermediate is also cross-signed by another certificate authority, IdenTrust, whose root is already trusted in all major browsers. Specifically, IdenTrust has cross-signed our intermediate using their DST Root CA X3.
This is entirely false.
what exactly ensures that the DV cert is a DV cert?
The fact that IdenTrust says it's a DV cert, and browsers trust its claims.