LWN: Comments on "Defending Our Brand (Let's Encrypt)"

Wildcards

tialaramex — Sun, 10 Jul 2016 02:01:20 +0000

These are all fair concerns, and indeed the choice to use wildcards to hide naming was a consideration when ct-policy was discussing name redaction. Under transparency all TLS certificates for the web PKI are public not only in principle but in practice, they're published to log servers when they're created. Redaction is a technology developed for a future version of the transparency system, allowing a certificate to be logged without including the full name of its subject. But even though the technology was developed, that doesn't automatically mean it will be permitted on the web. Proponents of redaction argued that if they aren't permitted to redact most of the name people will use wildcards to conceal naming. Those (like me) who are against redaction argued that if they resort to wildcards at least the logs will let everybody see the extent of the risk taken e.g. *.qa.example.com is a very different risk from *.example.com but who knows whether <redacted>.example.com poses a problem when the <redacted> part might just as easily be "www" or "jillspc.test04.qa"

Nobody knows what the actual limits are for SANs, Let's Encrypt arbitrarily stops at 100 names, others have done 120 or so with seemingly no issues. But you are correct that 1.1 million is probably far too many.

On the other hand, the cost of a single wildcard certificate from a commercial CA seems much more reasonable if you're doing something at a scale where 100 names just isn't good enough.

Wildcards

Cyberax — Fri, 01 Jul 2016 07:39:40 +0000

So get a separate certificate for each hostname. It's easy with Let's Encrypt, our clients now do it on a truly industrial scale.

You can even build a central certificate redistribution service.

Wildcards

flussence — Fri, 01 Jul 2016 03:34:46 +0000

I can understand the untrusted filesystem concerns. I'd be happy if it required some contrived DNS dance.

The main reason I'm interested in it is I'd like to have a bunch of subdomains covered, without giving nosy people a map of my entire infrastructure via SANs. It'd also be good for, say, something that wants to use subdomains as sandboxing (like Mozilla's bug tracker does — I don't think the browser would be too happy getting a certificate with 1.1 million hostnames in it).

Wildcards

tialaramex — Fri, 01 Jul 2016 01:18:26 +0000

Although there's no promise it will ever be part of Let's Encrypt, let alone soon, the capability to offer wildcards is a consideration in ACME.

For a DNS challenge, the rationale is that if you can prove you control DNS for foo.example, then it appears de facto you control *.foo.example because that's how the DNS hierarchy works.

However even if strictly a DNS administrator can be considered to control *.foo.example it may surprise their employers that this allows them to get a wildcard SSL certificate. Such nasty surprises are why HTTPS isn't an option for Let's Encrypt's "simple" HTTP based validation:

It turns out that LOTS of crappy shared hosting setups allow the owner of say aaa.aaaaaaa.example.org hosted on their systems to create an HTTPS site and then they'll serve answers from that site when they get requests for

https://anything-else-on-the-same-ip-address.example.com/....

so long as the real owner of the latter name didn't turn on SSL, because the connection arrived on the right web server, and it can't see a matching site, so it just picks the first one.

Let's Encrypt decided as a matter of policy that they want no part in the resulting shenanigans, and there's no immediate hope of getting all those shared hosts to fix this, so they removed the option of choosing HTTPS for the simple HTTP case before going live. But that's not because it doesn't work, but rather because in practice the effect would have been a nasty surprise for too many people.

Whether the same would be true for Wildcards validated by DNS (or by some yet to be conceived contrivance) is undecided as yet.

Defending Our Brand (Let's Encrypt)

Cyberax — Tue, 28 Jun 2016 16:55:33 +0000

Wildcard support is not going to happen by design, and I'm personally perfectly OK with that. ECs are being rolled out right now and DNS-based validation has been on since February.

Defending Our Brand (Let's Encrypt)

flussence — Tue, 28 Jun 2016 16:21:24 +0000

>But I'm still waiting for list of technical problems with Let's Encrypt. So far I only have a problem with their incomplete IPv6 support (which is being fixed).

Last time I tried LE, it was missing wildcard SAN support, EC certificates, and verification methods other than port 80. Not sure how many of those are fixed.

Private keys

Felix — Mon, 27 Jun 2016 11:37:17 +0000

StartSSL changed their web ui a few months ago and (AFAIK) it is no longer possible to let the CA generate the private key. Instead an CSR upload form is shown with the openssl command to generate the key (and a reference to a windows tool doing a similar thing).

Honesty

anselm — Mon, 27 Jun 2016 11:34:46 +0000

The main thing commercial CAs are trading off is _honesty_. They get beaten up (and eventually risk going out of business altogether) for bad security, and they lose money if they lower prices, but being _dishonest_ in certain ways doesn't attract more than a stern frown from the trust stores so long as it has no direct security implications and it can achieve more revenue without additional technical effort.

Oh, I agree with you completely. There is also the issue that there are various commercial CAs which are “too big to fail”, so apart from the obvious honesty issues they even seem to be able to get away with security boo-boos where everyone says “too bad, that shouldn't happen, no matter, let's get back to business as usual”. We probably have the Google Chrome folks to thank for their efforts to not let standards slip too badly (see last year's Symantec “Google test certificate” thing), because apparently you need to be Google-sized and brandishing a big stick in order for the likes of VeriSign to listen to you.

Private keys

tialaramex — Mon, 27 Jun 2016 11:06:49 +0000

I was thinking of the Baseline Requirements. But I see that actually the current BRs still only prohibit CAs from "archiving" private keys if they generate them and don't just outright forbid the practice.

However "CAs must never generate the key pairs for signer or SSL certificates" is part of Mozilla's current policy. So if there _are_ any CAs doing this, I'm quite happy to turn that into another chance to play beat up the commercial CA on m.d.s.p and wait to see if they'd prefer to go out of business or promise to fix it.

Honesty

tialaramex — Mon, 27 Jun 2016 10:50:27 +0000

Aside from my specific point about private keys, I think you're also a bit off in your estimation of what the trade-off is

The main thing commercial CAs are trading off is _honesty_. They get beaten up (and eventually risk going out of business altogether) for bad security, and they lose money if they lower prices, but being _dishonest_ in certain ways doesn't attract more than a stern frown from the trust stores so long as it has no direct security implications and it can achieve more revenue without additional technical effort.

One of the things that's unfortunate about Honest Achmed's Used Cars and Certificates (a CA inclusion ticket on Bugzilla raised to highlight problems with Mozilla policy many years ago) is that people focused in on how they need to write rules that would ensure Mozilla doesn't let Achmed run a public CA because he's setting the bar far too low but the shady "Used Cars" business has another bad side to it which was ignored in that discussion altogether.

Back in the dark days of "cryptography as munitions" both Internet Explorer and Mozilla (then as Netscape) had similar but different tricks to enable good cryptography if it was allowed, which relied upon basically flipping a bit in the site certificate, Netscape's was called "Server gated crypto". This costs essentially _nothing_ for the CA to do, and it achieves essentially _nothing_ on today's web because nobody is still running Netscape 4.x or Internet Explorer 5 or whatever other archaic stuff cared about that feature. So what you'd expect from an honest CA is that they'd either not mention this feature at all, or they'd list it as obsolete and say if you really must have it for some crazy reason that's a special order, but please read this document from the big browser vendors saying not to bother first.

But what you actually saw, certainly up to 2015, was that big famous CAs pushed this as a feature you needed to look for, something they were giving you that would unlock better cryptography than other certificates you might find cheaper elsewhere, or even an added extra for a few dollars. If the fact that it was technically obsolete was mentioned /at all/ it would be in some small print, and without much attempt to explain just how incredibly obsolete it actually was.

Or look at OV and "Classes" of certificate. Even today, big CAs will tell a potential customer that the more expensive certificates they offer are better because more facts are validated. Under the modern BRs they're at least right that unvalidated facts can't be listed in the certificate (ten years ago this wasn't true). But this isn't a benefit to the subscriber, their customer, at all. It's maybe, arguably, a benefit to the relying parties, who aren't buying the certificate, but even that's very dubious for anything short of EV. How many of your visitors actually inspect the x509 certificate in detail? Everybody else won't know if you spent that extra money.

Other less than honest tactics include: making a big deal of insurance that notionally pays out vast sums of money (the terms basically exclude every possible scenario in which anyone might claim, then to make doubly sure they require every claim to be completed for one individual and limit the payout to a small value per claimant); site seals (here is a GIF with a padlock symbol and your name that we claim is making you "secure"); and bundling unrelated software like anti-virus with the SSL certificate, in order to make the value proposition more confusing.

Unlike with security, the trust stores have limited interest in fixing this stuff. It doesn't screw _their_ users, the relying parties directly, only the subscribers who pay through the nose for certificates; and for the people doing most of the heavy lifting it's hard to remember that this stuff doesn't look obviously laughable to the layman. To you, or to me, a "site seal" is worthless garbage, but to somebody who just learned how to write HTML tags it's pretty impressive stuff. And the CA/B can't do much here either, even if it wanted to, because it _absolutely must_ avoid appearing to be a cartel. Cartels can get you in a lot of trouble unless you have a sovereign entity backing the cartel (which is why OPEC does fine). Security rules are fine, but "Let's agree not to sell this product in this way" is very definitely activity associated with a cartel, and nobody in CA/B wants to even _look_ like that's going on.

Private keys

Cyberax — Mon, 27 Jun 2016 10:01:27 +0000

> Because I think you'll find this practice, which is notoriously insecure yet so convenient, was outlawed for the web PKI.
Outlawed? Care to point the law in the legal code?

Comodo actually has a Java Applet that runs in the browser and generates the keypair and the CSR.

Private keys

anselm — Mon, 27 Jun 2016 10:00:44 +0000

Can you find a commercial CA that _today_ will send you a private key they generated corresponding to a certificate for, say, a web site ?

When I was last generating server certificates using StartSSL, uploading a CSR was possible-but-optional (and not the default). That was a year ago or so – I've since gone over to Let's Encrypt –, so they may have changed their approach in the meantime. And that's not exactly an unpopular commercial CA.

Private keys

tialaramex — Mon, 27 Jun 2016 09:44:39 +0000

Can you find a commercial CA that _today_ will send you a private key they generated corresponding to a certificate for, say, a web site ?

Because I think you'll find this practice, which is notoriously insecure yet so convenient, was outlawed for the web PKI.

There are CAs still doing it for S/MIME, because there you're not even dealing with somebody who has been following a web tutorial on how to install IIS, but someone who just got hired and given an email address and may not be in a fit state to spell their own name, much less issue a CSR. But S/MIME is "not our problem", there shouldn't be any left doing this for TLS / web certificates.

[ The practice also remains widespread for OpenVPN-style tunnels that use public key crypto, and for private CAs, but in both cases the web PKI can say those aren't its fault ]

Now, for resellers it's harder to absolutely police. But even looking at some pretty sketchy ones the worst I can find is a tool that says it generates the private key locally on your PC. Of course it's proprietary code, so you can't inspect it to check that's really how it works, but that's true of say, Windows itself and life goes on. If we believe them (and if we don't, why would you even think of using their service?) they never see your private key.

Defending Our Brand (Let's Encrypt)

anselm — Mon, 27 Jun 2016 09:03:39 +0000

If you're a commercial CA, your basic tradeoff is between being diligent about security and making tons of money. Commercial CAs are generally predisposed towards the latter, primarily because they don't have a lot to lose if they cut corners with the former – and it turns out that that is exactly what many of them will do given half a chance. For example, when you buy a certificate for your domain, many commercial CAs will, for everyone's convenience, send you both the certificate and the matching private key, which from a security standpoint is what you don't want (only you yourself should ever have access to your private key), but is way less hassle than having to futz around with CSRs. Also, if commercial CA X is too picky about certifying a customer, they run the risk that the customer will take their business to the (less strict) CAs Y or Z instead, which would suck if you're X.

The nice thing about Let's Encrypt, in this context, is that they're not in the game to make money, so their incentives can be different.

Defending Our Brand (Let's Encrypt)

Cyberax — Mon, 27 Jun 2016 07:20:34 +0000

Ha. Hahaha. HahahaROTFLLOL.

I can get a certificate from Comodo or StartSSL for a couple of bucks (or even free), and the only documentation I need in this case is a WHOIS record or a special DNS entry. Without any human interaction from CA's side and certainly no trademark searches or document checks.

And anyway, CAs do NOT enforce trademarks. That's a job of domain name registrars.

But I'm still waiting for list of technical problems with Let's Encrypt. So far I only have a problem with their incomplete IPv6 support (which is being fixed).

Defending Our Brand (Let's Encrypt)

asaz989 — Mon, 27 Jun 2016 07:12:18 +0000

The technical reasons being that a Certificate Authority is not a purely technical institution. Things like auditing, vetting of delegated sites, and yes, controlling your trademark, are also part of the job.

Trademark does NOT require registration

david.a.wheeler — Sun, 26 Jun 2016 23:24:57 +0000

Getting a trademark does NOT require registration. From Wikipedia: "It should be noted that trademark rights generally arise out of the use of, or to maintain exclusive rights over, that sign in relation to certain products or services, assuming there are no other trademark objections."

There are legal advantages to registering a trademark, but it's not free. There are lots of trademarks that are registered, and applying for trademark registration does NOT mean that the applicant gets the trademark.

Now sorted out apparently

roc — Sun, 26 Jun 2016 21:28:50 +0000

Ouch, Comodo really lost big here. Maybe not registering the trademarks paid off for Let's Encrypt after all :-).

Defending Our Brand (Let's Encrypt)

Cyberax — Sun, 26 Jun 2016 18:40:25 +0000

Yes, and it works fine for me.

Defending Our Brand (Let's Encrypt)

jaromil — Sun, 26 Jun 2016 09:29:29 +0000

Do you use Let's Encrypt?

Now sorted out apparently

rahvin — Sat, 25 Jun 2016 03:37:00 +0000

It was the press that did them in. Nothing could have harmed them more than the CEO's post in the support forum. That thing was filled with childish nonsense.

Glad to see they realized the error of their ways and abandoned the foolishness. After all, registering isn't required, it would have been trivial for Let's Encrypt to show (though not without cost) they had been using the mark and that Comodo lied on their application when they said the mark wasn't in use. Had Comodo persisted, that lie filed on government paperwork would have exposed the company and the person that filed it to potential perjury charges and a possible civil suit. Though I do believe it was all the bad press that finally convinced them this childish gambit was stupid and poorly thought out.

Nothing like making a statement in an industry that sells trust by doing something entirely childish and stupid to expose how trust worthy you are. I hope this harms Comodo's business. God knows I'd never trust a company run by a CEO that makes forum posts like that.

Now sorted out apparently

richmoore — Sat, 25 Jun 2016 00:01:07 +0000

Confirmed https://letsencrypt.org/2016/06/23/defending-our-brand.html

Now sorted out apparently

richmoore — Sat, 25 Jun 2016 00:00:22 +0000

https://forums.comodo.com/general-discussion-off-topic-an...

What we were _expecting_

tialaramex — Fri, 24 Jun 2016 12:53:12 +0000

Let's Encrypt was expected to be disruptive. While it's true that some commentators said they expected Let's Encrypt to make no difference whatsoever (e.g. David Holmes at F5 said back in 2015 it had "no business model" although today his company says it sees a "lot of demand" for making Let's Encrypt work with its products...) mostly people expected the automation and publicity combined to have some impact.

The sort of impact that was hoped for was what we saw from Amazon and some cheap web hosting companies. Offer either the same features (SSL certificates at no cost to the subscriber on AWS) or literally the same product (Let's Encrypt certs come with the hosting at providers like Dreamhost now) and essentially make that part of the baseline of what people should expect, rather than an optional extra they might get charged for.

Beyond that it was reasonable to expect commercial SSL providers would find ways to adapt. Over the past 12 months several announced new offerings that either position a DV certificate (like the ones from Let's Encrypt) as their free "bait" offering, with trade ups to certificates that Let's Encrypt don't offer such as wildcards, or EV, or they focused on what were once fripperies but are now the centre of their product line-up such as insurance, call centre support or the ever popular "site seal" and de-emphasised the SSL certificates that are now comparable to a $0 product elsewhere.

And it was foreseeable that some, particularly Symantec with their stable of long-lived roots, would work very hard to portray all other CAs, but Let's Encrypt in particular as less trustworthy than them. That's a dangerous game (Symantec already got really bad press recently for their bogus "test" certificates, and its CA/B rep keeps pushing for smoke-filled room compromises on SHA-1 that could blow up badly too) but at least it has something to do with the real purpose of these companies, maybe Symantec really do think ISRG is less trustworthy than they are.

It was NOT expected that people would try bogus trademarks, or indeed that they'd start publishing smear stories about Let's Encrypt. To me that steps over the line from vigorous competition to dirty pool.

There are people at Comodo doing really good work, https://crt.sh/ has the Comodo name on it and doubtless costs Comodo not a little money to build and maintain. But this trademark nonsense, and particularly the childish defence of it by their CEO is just wrong.

Defending Our Brand (Let's Encrypt)

pboddie — Fri, 24 Jun 2016 10:07:38 +0000

Ah, so it's a trick from the passive-aggressive playbook, is it? I remember when some company tried to register Python as a trademark while pretending that it somehow wasn't an established name for an established product presumably used by the very thing they were trying to brand with their own rogue trademark. The next step is always an indication that they weren't going to enforce their trademark, or that they won't pursue it (but, of course, reserve the right to do so, and may even obstruct others from doing so).

Defending Our Brand (Let's Encrypt)

tialaramex — Fri, 24 Jun 2016 09:22:41 +0000

I would guess that the specific phrase chosen for their mark makes a huge difference here.

"Let's Encrypt" is a phrase lots of people might use in a relevant context that doesn't uniquely describe this product/ service, compare for example "Red Hat" Linux or "Cisco" networking, which seem fine, versus "Windows" or "App Store".

Registering that latter sort of mark is definitely an aggressive thing to do - legal, but aggressive. And it may well not pay for a new non-profit to start by making aggressive trademark applications before the community sees them doing anything _useful_. So I can see why they would decide not to do it since registering is NOT obligatory. And actually one of the things I've been disappointed by on this is how many people rushed to say "Oh, if you don't register you have to expect this" as if somehow we should expect these notionally trustworthy entities like Comodo to try to find the most under-handed and devious ways to act they can come up with and not think less of them for it. The reality is that moral judgements _are_ a factor in the relationships between the CAs and the trust stores (on behalf of relying parties).

Check out how many eyebrows were raised about Symantec issuing dubious partial wildcard certificates to KPMG. KPMG is their auditor. Symantec has tried to play this very nonchalant, like, hey, we do issue these certificates to a few people and it so happens that KPMG are a huge global corporation which wanted to buy these certificates, the fact they're our auditor is a coincidence. And mostly the fall-out was that maybe these certificates should just be explicitly prohibited‡, rather than existing in a dubious grey area. But the "coincidence" of them being issued to KPMG didn't go without notice.

‡ They don't actually work in say, Firefox, or I believe Chrome, but the question isn't whether they should work, but whether they should even _exist_.

Defending Our Brand (Let's Encrypt)

Cyberax — Fri, 24 Jun 2016 08:59:53 +0000

> You make a good point there. This calling for attention because of being trademark trolled by usual suspects while saving the (rather huge) amount of money gathered through sponsors is somehow naive and shabby.
Why?

> They should have registered (r) a (tm) first and foremost.
Why?

> I'm starting to be wary of Let's encrypt also for other technical reasons, this just sums up to a growing perception of their amateur conduct.
The technical reasons being?...

Defending Our Brand (Let's Encrypt)

jaromil — Fri, 24 Jun 2016 08:31:35 +0000

You make a good point there. This calling for attention because of being trademark trolled by usual suspects while saving the (rather huge) amount of money gathered through sponsors is somehow naive and shabby.
Life is hard being honest, work with it!
They should have registered (r) a (tm) first and foremost.
I'm starting to be wary of Let's encrypt also for other technical reasons, this just sums up to a growing perception of their amateur conduct.

Defending Our Brand (Let's Encrypt)

Zenith — Fri, 24 Jun 2016 07:44:34 +0000

I may be reading this wrong, but it seems like they are not pursuing the trademarks?

With LE now being an operational business, we were never going to take the these trademark applications any further. Josh posted a link to the application and as of February 8th it was already in a state where it will lapse. Josh was wrong when he said we’d “refused to abandon our applications”. We just hadn’t told LE we would leave them to lapse. We have now communicated this to LE.

https://forums.comodo.com/general-discussion-off-topic-anything-and-everything/shame-on-you-comodo-t115958.0.html;msg837436#msg837436

Defending Our Brand (Let's Encrypt)

spender — Fri, 24 Jun 2016 02:09:42 +0000

The (R) was there even before our trademark problems (since 2011), but if you're a multi-billion dollar corporation in this country, there's not much you can't get away with.

-Brad

Defending Our Brand (Let's Encrypt)

karkhaz — Fri, 24 Jun 2016 02:01:33 +0000

> have had dealings with trademarks in the past

Couldn't resist browsing over to the grsecurity site just now, it's good to see that there's a nice (R) in front of the grsecurity name :)

*sigh* this does seem very unfortunate. If anything, I suppose it's nice that the big status-quo players are are using underhanded legal arseholery to bully innovative projects like Let's Encrypt, since it shows that they're unable to compete any other how. (The CEO's assertion that Let's Encrypt had stolen Comodo's buisiness model, that somebody linked to above, is truly pathetic). But this does seem like something that could have been prevented.

Judging by the number of times this kind of thing happens, I wonder if it's worth having some kind of checklist that FOSS projects can use to protect themselves from legal trolls (but also to ensure that they're in compliance with the law in general). Even something like the Badging Project for code quality [1], but for legal rather than technical issues. I suppose umbrella organisations like the SFC or FSF or Gnome Foundation or whatever go through some formal process when a project joins them, maybe it's worth making these public?

I understand that in many cases these will be country-specific (whereas the Badging Project can be more universal, best practices for code quality are similar across all languages :). But it still would be nice to have; even if initially only US-specific advice, since that's where all the litigious scum seems to fester, and most projects of a certain size will want to establish a legal presence in the US at some point.

[1] https://lwn.net/Articles/690169/

Defending Our Brand (Let's Encrypt)

spender — Fri, 24 Jun 2016 01:36:06 +0000

This is correct (IAANAL, but have had dealings with trademarks in the past). I'm not sure why they wouldn't have registered the trademark if they care about the brand -- it's certainly not expensive to do so. Had they registered it, Comodo's applications would have failed at the initial search stage. Filing trademark oppositions are apparently quite expensive (http://www.inta.org/INTABulletin/Pages/TheValueEquationof...) and with winning an opposition not awarding attorney fees (http://www.inta.org/TrademarkBasics/FactSheets/Pages/Oppo...) it's almost not worth it to go that route, but if they think they could win, an ACR might be an option (http://www.uspto.gov/web/offices/com/sol/notices/acrognot... http://www.inta.org/INTABulletin/Pages/AcceleratedCaseRes...)

Definitely an unfair move by Comodo (I guess upset about the competition) but also possibly penny-wise and pound foolish by ISRG. If you can afford the accounting requirements of a non-profit and have all the sponsors listed at https://letsencrypt.org/sponsors/ , you can afford the < $1000 for a trademark.

Of course, though this is one instance where the legal system would have actually worked to prevent the specific action of Comodo obtaining the trademarks, my own experience shows that if the ISRG can't afford an ACR, they wouldn't be able to afford to do anything if Comodo simply uses the Let's Encrypt trademark without the registration in place.

-Brad

Defending Our Brand (Let's Encrypt)

ira — Fri, 24 Jun 2016 00:52:23 +0000

IANAL!

https://en.wikipedia.org/wiki/Trademark

The article seems well written and explains things well for those who are curious. (I fully acknowledge that Wikipedia can be full of crap. But in this case, it lines up with what I've heard via other sources.)

The TM clearly says they have NOT registered it.

They'd have used R if they registered it.

Defending Our Brand (Let's Encrypt)

karkhaz — Fri, 24 Jun 2016 00:08:11 +0000

This is obviously evil, but I don't understand. On one hand, Let's Encrypt claims (on their Trademark Policy page [1]) that "Let's Encrypt™" is one of the trademarks "owned or used" by the Internet Security Research Group. Is that significant? Has ISRG actually _registered_ the trademark?

On the other hand, one of Comodo's shills is claiming [2] that Let's Encrypt "should have trademarked this when they started using it publicly in November of 2014". Is it really true that ISRG hasn't registered the trademark, can somebody clarify? They don't mention that the trademark is registered from the blog post linked to from the summary.

It would be really sad and terrible if Comodo prevailed because nobody registered the trademark before :( this was already discussed on LWN a while ago [3] wrt the GNOME-Groupon spat (search the page for "register trademarks used by your projects".

[1] https://letsencrypt.org/trademarks/
[2] https://forums.comodo.com/general-discussion-off-topic-an...
[3] https://lwn.net/Articles/654124/

Defending Our Brand (Let's Encrypt)

mathstuf — Fri, 24 Jun 2016 00:07:30 +0000

A report on Reddit (of a Tweet) says they were marking any email from a Let's Encrypt-using domain as spam too. The company is awful.

Defending Our Brand (Let's Encrypt)

bmds — Thu, 23 Jun 2016 23:01:25 +0000

The fraudulent certificates created a few years ago by one of their "trusted partners", and now this. This company goes on my personal blacklist.

Defending Our Brand (Let's Encrypt)

roc — Thu, 23 Jun 2016 22:14:47 +0000

Wow, that's pure evil.

Defending Our Brand (Let's Encrypt)

bagder — Thu, 23 Jun 2016 21:54:47 +0000

Comodo CEO spoke up (at https://forums.comodo.com/general-discussion-off-topic-an...)

(lots of talk but then he ends with...)

"Lets get the facts right guys! We are the good guys that have been giving free SSL certificates since 2007 and managing them!"