Reason for Revokation of


Continuing the discussion from Certificate Revocation, April 5 2016:

It would be nice if there is some information why the certificate was revoked.
Because there where earlier request for revocation based on malware. So it would be great to get the reason.
Since it was not based on the user but on an third party.

Certificate revocation

According to the transparency log, one of the SAN names in the certificate is . That domain does not look to be owned by Microsoft in the WHOIS but uses a name well associated with Windows and looks to be owned by a third party. One can only guess that Microsoft suspected malware could be used on that domain and requested the certificate be revoked in compliance with their Root Program requirements. I can see that domain name easily being used in emails and looking somewhat ‘genuine’.


Good point i missed these domain in the first look. I can understand that this is an security risk
but again i want to mentioned that it should be more transparent what is blacklisted and why an
cert is revoked.
I am sure that not all “windows” domains could be claimed by M$ nor even been protected.
For example or
And if the page content define if it the domain is valid/worth an certificate than i would say
it is not far from censorship. So this point should be more transparent.


Maybe @jsha can respond to all these.


I’m pretty sure it’s not a case of “Windows” on it’s own being censored. The full name “Windows Notifications Center” refers to an actual feature within PC editions of Microsoft Windows 10 (an optional icon in the taskbar on the bottom right), hence why it is plausible as a name Microsoft could object to someone else using in a URL for secured browsing. I’m pretty sure Microsoft themselves hold the answers as to why they requested the certificate be revoked and they do not have to give Let’s Encrypt (or indeed any CA chaining to a root certificate in their root program) a reason for doing so. Non compliance would put the CA root in jeopardy. Let’s Encrypt look like they are simply trying to be transparent in the best way possible with what information they have available: the fact the certificate was revoked and who requested it. As for whether the content of the page at is objectionable, it simply returns a single line of text - 404. It is perfectly conceivable that there are hidden folders on the domain with phishing forms, for example. If this is the case, perhaps Microsoft came across these themselves after complaints- after all the domain was registered back in January and the certificate issued in February. It’s taken until now (April) for Microsoft to decide to request revocation.


Though I understand the argumentation behind such initiative from Microsoft’s side, I think they’re at fault.

If they feel they have good reasons for applying their version of justice (who has or hasn’t the right to a certificate) they should take the proper way to impose their laws.

If they feel so strongly about someone using ‘windowsnotificationcenter’ in a URL, then they should argue that the TLD ‘’ should not be given out in the first hand. If so, they would have to convince an Internet registrar to dance the M$ music, which could require more efforts (depending on the registrar) than putting up their power against a US based organization.

Bear in mind that M$ did a huge mistake in their choice of name. We all knew of the word ‘windows’ long before M$ existed. At least 1000 years before. And yes, we have reasons to use it as the first word in a sentence now and then, thereby spelling it with a capital ‘W’.

If I understand it correctly, there’s now someone holding a TLD (and paying for it), maybe running a business under the mentioned TLD, and suddenly being refused a certificate for the legally held TLD because M$ has deemed it inappropriate?

The fact that a CA accepts to play by M$'s rules and obey to M$'s wishes (which admittedly does have some sort of logic to it) means that the CA does two things I disagree about:

  1. They apply censorship (wasn’t this something we’ve read should not take place?).
  2. They obey to an external company’s policy rules.

What happens next? Someone who runs a business in the name of ‘Schaffter’ (they do exist) which also happens to be my family name, turns over to say that if they can’t object to me holding the TLD, they’ll at least hinder me from getting a cert for it? And the guy holding a TLD including the word ‘electricsaw’ would be refused because some tool company claims they have an ‘electricsawservice’ department?

My opinion :

If I hold a TLD it should be possible for me to hold a cert for the same TLD. If I can’t get a cert, then the root case should be addressed, i.e. someone trying to refuse me the cert should try to refuse me the TLD, not the certificate.

Let’s Encrypt (and all other CA’s) should NOT dance to the music of any external company trying to protect their economical interests (Don’t even try to convince me about the “for the user’s interest” thing. I’ve been in this business and on this planet too long to believe in that ****.)


I agree with you. Applying corporate policy can easily leads to abuses. If someone do not have the right to have a certificate for it should not have the right in the first place to own the domain, and so action should be taken at the registry level. If I am not mistaken, in US law (the TLD .com is a US TLD), this require a decision from a juge. Only a judge can decide if a domain is legal or not with regards to the law in a free country, and I’ll like to be the same for certificates issuance.

If the site has been clearly spotted as doing some phishing (actualy impersonate a Microsoft website, not juste use a domain that look like it), if an early block (before a justice decision happened) should take place, It should be on the browsers level. Not specially on the CA level. In any case, reasons should be clearly explained and the early sanctions only temporary.

Just for the record, a TLD (Top Level Domain) is a domain like com, org, fr. is usually called a SLD (Second Level Domain).


A UDRP can take months, and addresses a legal right to use a domain name under ICANN’s rules.

The SSL certificate has nothing to do with ICANN. It just implies a secure, trusted, connection. That trust comes from the User trusting a Software/Browser vendor, who in turn trusts Certificate Authorities.

In this case, Microsoft isn’t just a random company filing a complaint over a trademark – they’re the company that enables (or disables) the ISRG root certificate into systems and devices for their users. They vouched for the security of ISRG and enabled the root certificate, who are then vouching for “” and signing that certificate. Microsoft essentially becomes complicit in conveying “trust” and security on their own platform, to a mark that is confusingly similar.

The certificate revocation also isn’t about the “right” to own or “use” a domain name; it’s about a visit to that domain showing the “trusted” secure lock in a browser on their operating system. People can still visit the domain in question and use a non-trusted certificate to secure the connection; the domain simply won’t be included in an implicit chain of trust that flows all the way back to Microsoft.


Of course. You’re absolutely right. That was inexact of me and I do know better. Thanks for pointing it out, Nit.


That is exactly my point.

I asked myself; What’s the use of a certificate? What is it good for?
And especially; What is it not good for?

I believe a certificate shouldn’t even try to guarantee the quality of the contents of the site. Also not guarantee that it’s contents or intentions are legally or morally ‘sane’. (Who’s to say?) Nor that it looks or doesn’t look like any other site. (Problems that could and should be dealt with in completely different ways.)

I believe it should do it’s best to guarantee that it actually is the site it technically claims to be and that you may communicate with the site resting assured that no one may eavesdrop the information exchanged with the site.

Microsoft’s acceptance or non-acceptance to trust the ISRG root certificate for its buyers should not put them in a position to apply indirect censorship on the sites having proved to be who they claim to be to Let’s Encrypt. That would create a very delicate situation for Microsoft and a very uncomfortable situation for Let’s Encrypt and its users. And one could only speculate how such censorship potentially could be (mis-) used in such a future.

Imagine having to go through an MACF (*) test once every six months or risking to loose the rights to the Let’s Encrypt certificate for your site.

And then, there’s Apple. And Google (Android). And so on and so forth…

(*) Microsoft Approved Contents and Functionality test.


Seriously? Then stop complaining and use a self signed certificate.

You just said:

but now you’re claiming the cert has nothing to do with the validity of what the site claims to be. You can’t have it both ways - either a Certificate Authority is backing up the validity of the site, or the CA has no bearing on the sites validity and you may as well use a self signed cert.

Make up your mind.


I agree with @Biker. The purpose of a CA is to issue certificates to the entity controlling a domain name, as determined by ICANN. It is troublesome to allow or encourage private entities to make arbitrary decisions secondguessing this. Of course the ICANN regime is private in itself, which creates its own problems, but adding further layers of arbitrary, unaccountable decisionmaking is not a gain for the openness, transparency and fairness of Internet infrastructure.

Let’s suppose, hypothetically, that Microsoft followed the proper procedure to challenge the registration by issuing a UDRP trademark complaint via ICANN. Let’s also suppose they lost. But under this contractual arrangement, this condition of their root programme, they’re still perfectly free, it seems, to try and obstruct the use of such a domain name, even if ICANN deems it legitimate. Moreover, the biggest issue with this is that such revocation orders affect all CA users, not only Microsoft users. There are various other avenues which Microsoft could pursue which are less troublesome; anti-phising lists, revocation lists pushed to IE (I gather all browser vendors are doing this now).

Since any CA is going to want inclusion in the Microsoft root programme, this is essentially a way for Microsoft to decide what websites get to use TLS, and eventually (as use of TLS becomes essentially mandatory, especially for newer web platform features as is intended), whether websites are allowed to substantially exist. This is not necessarily a power that will be abused, but it’s also one I’d argue it’s not Microsoft’s place to possess. This also circumvents the whole CA/B Forum process of determining certificate issuance criteria.


Then go to a different signing entity. You know why virtually none will supply a cert for Because the domain is deceptive in nature and nobody wants to back such an obvious malware site.

This is hardly an arbitrary decision - would be fine, because it’s not directly using a trademarked part of the world’s most widely used desktop/laptop OS. But is obviously trying to sound like an official part of the Windows ecosystem, being named exactly like a component on Windows.

Let’s not, since that’s a complete non-sequitur. MS isn’t challenging the domain, nobody have ever said MS is challenging the domain. Biker himself complained that the cert should be available since the domain was validly obtained.

All MS (and Let’s Encrypt and StartSSL and any other legit CA) are doing is refusing to validate that domain.

And so they shouldn’t. Biker can generate a self signed cert for whatever domain he gets, but he can’t get international recognition if the domain is likely to appear to be from a separate recognised organisation.


There’s a very interesting blog post on this topic from a couple of months ago, along with a lengthy discussion of the policy. The short version is that Let’s Encrypt agrees that CAs should not be a judge of quality or legitimacy when it comes to DV certificates. DV merely verifies that a public key belongs to a domain.

At the same time, that’s exactly how existing CAs have conducted business and marketed their products for decades (think: site seals and what not), so it’s not something that a new player can just completely ignore. That’s why Let’s Encrypt is currently checking Google’s Safe Browsing API before certificates are issued.

In the end, I think this is a user education and browser UI problem. Users have been told to look out for “the lock” as a sign of authenticity for decades, but that’s not really what it is. Once we get to a point where regular HTTP can be marked as insecure, the UI for DV could be changed to look like HTTP does today, and the “secure” look can be reserved for certificates of a higher validation level, where the authenticity of the certificate owner has been verified to a certain degree.

Finally, just a gentle reminder: Try to be agreeable, even when you disagree. This is an important conversation to have, and it would be in everyone’s interest to keep the discussion to the facts.


(I pointed out a typo, which pfg has now fixed, nothing to see here)


Yep, thanks! :blush:


Will any explanation be given by Let’s Encrypt staff that did that? Since the matter is very interesting…


If I hold a TLD it should be possible for me to hold a cert for the same
TLD. If I can’t get a cert, then the root case should be addressed,
i.e. someone trying to refuse me the cert should try to refuse me the
TLD, not the certificate.

Let’s Encrypt (and all other CA’s) should NOT dance to the music of any
external company trying to protect their economical interests (Don’t
even try to convince me about the “for the user’s interest” thing. I’ve
been in this business and on this planet too long to believe in that

I don’t think anyone is trying to reduce your property rights.

What happens when that certificate is used to phish you, your family or your friends? (I often use my mother and father as worse case, so its not meant as an insult. It drives home the imperativeness).

We need the DBOUND Working Group ( to provide a solution for domain administration boundaries.


Microsoft asked us to revoke because of “unwanted” software on one of the domains (the .online one, don’t recommend visiting it). They were also concerned about one of the domain names ( We do not know details about the unwanted software, for the most part we just know that the Microsoft root program required us to revoke and we need to comply with root programs.


when you guys have to obey MS’s root program, is the ISRG already trusted by MS?