What NameCheap is saying about LetsEncrypt- from a support blog

Feature Requests
1

I’m a user, tho I’ve set up Linux boxes.
I DON’T understand the tech discussion here, but I thought maybe someone else would, and might want to deal with NameCheap. Or not. I don’t need help with this feature directly but thought using LE on NC would be neat. YMMV?

Joshua Vogel Julia Zemetskaya • 20 days ago
Hi Julia,

I host several sites on namecheap, and I’m considering moving them because of this ridiculous policy.

There is no logic behind the notion that a private company charging money for a service is any more secure than a transparent, publicly audited alternative.

Using a private, for-profit certificate issuing authority will cost me more annually than your hosting fees! Are you kidding me? I’d be saving money to move to one of the many dozens of hosting companies that charge comparable amounts, but let me use Let’s Encrypt.

Tell whoever is in charge that this is an idiotic business decision, and that you’ve got at least one really annoyed customer here.

Julia Zemetskaya Mod Joshua Vogel • 18 days ago
Hello Joshua,

Thank you for your feedback on this matter. We do understand your concerns for sure.

Though we believe increased web security is a good thing, we also think that using certificates from free providers can get more risk and uncertainty into your business.

Additionally, we would like to draw your attention to several disadvantages and drawbacks of Let’s Encrypt certificates:

  1. No OV/EV support or possibility (no possibility to issue a certificate with medium or high assurance and user trust level);

  2. No Windows/IIS support for now (impossible to issue a certificate on IIS/MSX environment);

  3. Insufficient level of domain validation and the absence of brand validation ( All publicly trusted CAs are flagging the certificates containing IT, financial and other public words, brands etc for additional security checks, which is not applicable for LE.)

  4. Multiple machines hosting the same name can’t get a separate cert for each machine ( in a nutshell, it is not possible to reissue the certificate, makes the server vulnerable for DROWN attack).

  5. No policy on automated blacklists: once you are blocked by the system (for hosting malware) you cannot get a new cert for some period of time.

  6. Cipher suite configuration is still manual (the certificate installation is automated, all other settings are manual).

  7. Root access needed to install and run ACME-script. Indeed, some plugins can be installed on shared servers, still they do require at least sudo-user access (due to the fact that for certificate installation “httpd” process should be reloaded, which cannot be done by non-sudoer). Users with “jailed” access (non-sudo) do not have rights within Linux shell for such operations.

  8. Script is able to overwrite server configs (such practice is considered insecure due to ability of script to upload, execute, write and read system files, which exposes the server and kernel for multiple vulnerabilities).

  9. No wildcard support (impossibility to issue a wildcard certificate that can cover 1 domain and all same-level subdomains).

  10. Exposing the private key to third-party (it is considered as insecure practice, as once the private key is compromised, it is relatively easy to strip HTTPS session and sniff data within decrypted channel).

  11. Multiple vulnerabilities of ACME protocol and attacks on it ( for example, MitM-attack on integrity check, signature reuse on ACME-connection itself, DNS injections, DNS attacks etc. More info about that can be found in multiple sources, e.g: https://tools.ietf.org/html… , https://www.agwa.name/blog/… , https://github.com/letsencr… etc . )

  12. Impossibility of adding custom or server-specific OIDs (object identifiers) SSL certificates ( as LE PKI is cross-signed, it is not possible to alter it within given restrictions).

  13. Validity period (for LE certificates - only 90 days, for all trusted certificate provides - up to 39 months).

With all that being said, it is still possible to install LE certificate on our shared server via SSL/TLS manager >> Manage SSL Sites if you have a certificate, private key and CA bundle codes in separate files.

Additionally, it is possible to install LE auto-installer on VPS and dedicated servers.

Since the nature of shared and reseller hosting implies having a significant number of independent customers’ accounts on the same server instance, we cannot put at risk our other clients by enabling not fully secure technology.

Best regards,

1 Like
2

Let’s debunk that…

  1. True, but doesn’t justify the cost of DV…
  2. Manual issuance is possible
  3. The “brand validation” only prevent other to issue certificates, so you still get it from them if you use LE…
  4. False (except for large number of certificates, where rates limits apply)
  5. (Maybe somebody else can comment?)
  6. What the link ?
  7. No, root access is not needed for an ACME script.
  8. Only if you want to
  9. True, but doesn’t justify the cost of not-wildcard-DV…
  10. No. Except if you call third-party a script. (And, with a CSR, you can avoid it too)
  11. Probably the email-based insurance is safer… sigh
  12. (Maybe somebody else can comment?)
  13. True. But if the issuance is automated, it’s not a concern.
1 Like
3

12 is a bit like with wildcards. If you need something custom, then to be sure, Let’s Encrypt is not for you because they don’t do custom. The vast majority of bulk hosted sites don’t need anything custom.

OIDs are how the X509 certificate system is extensible. They’re a tree of ID numbers like the way DNS is a tree except with arbitrary integers instead of strings. So when we say Subject Alternative Name for example we mean 2.5.29.17 but in principle anybody could have part of this tree, just maybe you’d find yourself with unwieldy numbers like 2.67402.19.33520.11042916. And everybody on the web agrees to care about 2.5.29.17 but probably they don’t care about some new OID you minted.

1 Like
4

Nonsense. It's true that certbot doesn't run on Windows, but there are other clients that do.

Absolutely false.

...and this is unique to LE how? This is going to be the case with any CA's cert.

Depends on the script; many of them run just fine without root access. But yes, to reload the httpd process, they'd need some sort of root access.

Not without root access (see above)

True, but how often is this really necessary? Especially if you can get certificates for arbitrary hostnames on demand, and at no cost?

Certbot doesn't expose the private key to any third party. None of the alternative locally-installed clients expose the private key to any third party. There may be a web-based LE client that generates its own private key (and thus exposes it to that party), but that is not a recommended practice.

...so that "we cannot put at risk our other clients" is pure BS--if using an LE cert put anyone at risk, that risk wouldn't depend on how that certificate was installed.

5

Though NameCheap isn't named explicitly, we have responded to this extremely inaccurate support message before:

4 Likes
6

Thanks, folks! I figured this was BS, but I thought it might be helpful to see who’s dissing you.

1 Like
7

@VWFeature
One part of that email is true:-

Apropos of the spurious claims the email makes - here's some pertinent facts they inadvertently left out:-

  • NameCheap are just resellers for Comodo (unlike LetsEncrypt there is no reason why I'd put a great deal of trust in how they manage that process). At best they're going to be no more secure than Comodo - who might only be considered secure if optimism triumphs history.
  • Comodo CA has previously had their "security" breached.
  • Comodo CA certificate resellers have previously had their "security" breached.
8

I think the best statement that really addresses this issue in non-technical terms is if you are making money with your site and if your site needs customization LetsEncrypt certificates are not for you.

For most of us using we are host non-commercial or minimally profitable commercial sites where buying a certificate from other CAs would be impactful.

9

We do welcome commercial use; unlike previous free certificate services, our terms of service don’t forbid it at all. We’re used successfully by a large number of commercial sites, including for online shopping, for example by all Shopify sites

We’re also happy for people to customize their sites that use Let’s Encrypt, and I assume that many people do.

The main reasons I’ve seen on the forums where people were happier buying a certificate from a different CA included wildcards, familiarity with the other CA’s processes, and being forbidden by policy to install software or make configuration changes to satisfy our challenges.

1 Like
10

Note 2. (Windows).

I have got fully automated script to work on Windows XP. (Yes, Win XP)
I wrote an MSDOS batch file that calls the Perl script. Works every time.

John.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.