Yeah this should be revoked. Mozilla's CA acceptance programs mandate that the CA revokes the cert if the key gets compromised, and I presume others do too.

> If you have a test domain you can stick it on CloudFlare and get a certificate for free without the private part becoming public.

It all comes down to the fact that CA's don't want you to sign your own certificates, even when it's one of your subdomains unless you pay the big bucks. Best thing to do it still to create your own CA and sign certs for these kinds of things since it's meant for testing and development anyway. It's not that hard, anyone can use some command line can do it.

I'm surprised there's no "CA-tool-as-a-service" where the CA provides an API (and maybe a CLI tool that uses that API) allowing you to automatically request-and-generate certs from their CA server provided it's for a subdomain of a domain you have on your account.

That's essentially what Let's Encrypt aims to be: https://letsencrypt.org/

Have a look at the "certificate" section of Gandi's API https://github.com/Gandi/gandi.cli/blob/master/gandicli.man....

And check out SSLmate https://sslmate.com/

Check out OpenStack's Anchor project, it is exactly this.

If the people behind the post used anchor, then the issues mentioned here would be absolved.

Nearly every CA has an API already, you can add automated Domain validation yourself over a weekend.

Typical way to tackle sub-domains would be to issue a wildcard certificate.

This would be for subdomains with their own "sovereignty"; e.g. Tumblr or Wordpress blogs, where the subdomain "owner" could conceivably want to issue their own subdomains, or, heaven forbid, do client-cert signing for their subdomain.

SSL Labs test confirms that it has been revoked: https://www.ssllabs.com/ssltest/analyze.html?d=52-0-56-137.s...

Already happened....

Secure Connection Failed An error occurred during a connection to 52-0-56-137.sslip.io.

Peer's Certificate has been revoked.

For anyone else wondering: run Firefox on https://52-0-56-137.sslip.io/

It'll be gone in Chrome when the next CRLSet is fetched: https://scotthelme.co.uk/certificate-revocation-google-chrom...

That it's nor revoked yet doesn't reflect well on COMODO at all, not that it's the first thing that doesn't...

Came here to say the same thing.

Doesn't the CA forum baseline require a revocation if the private key is published?

https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.p... on page 18:

    The CA SHALL revoke a Certificate within 24 hours 
    if one or more of the following occurs: 
    (...)
    3. The CA obtains evidence that the Subscriber’s 
    Private Key corresponding to the Public Key in the
    Certificate suffered a Key Compromise or no longer
    complies with the requirements of Appendix A;

COMODO policy is compliant, they just didn't act on it yet

https://www.comodo.com/repository/Comodo_CA_CPS_4.1.4.pdf

4.9.1 Circumstances for Revocation Comodo may revoke a digital Certificate if any of the following occur:

A personal identification number, Private Key or password has, or is likely to become known to someone not authorized to use it, or is being or is likely to be used in an unauthorized way

Well, if the buyer of the certificate authorizes everybody to use the private key, technically it's not a "use [...] in an unauthorized way".

It may be unauthorized per Comodo's TOS.

I was actually looking at the comodo website to figure out if I can submit revokation on my own (we've got the key after all...). Gave up after looking at 20+ pages. Apart from a login site for email cert revocation, I can't find any reasonable contact.

Comodo website is not that good apparently.

Edit: in the document posted by brohee: (about authentication for certs revocation) "OR the Subscriber must be able to send an S/MIME email signed with the private key associated with the Certificate". That's doable :)

[email protected] it is

4.9.2 Who can Request Revocation A Subscriber or another appropriately authorized party can request revocation of a Certificate. An authorized party includes an RA, regardless of whether on behalf of the Subscriber may request revocation through their account. Other parties may report suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates, in the first instance, by email to [email protected].

Hm, how is that compatible with Startcom's policy of charging for revocation?

Mozilla should probably add 'charging for revocation' to their list of problematic practices (required to be included in Firefox). Not that revocating compromised certificates isn't already required, but just that some behavior by poor CAs needs to be explicitly pointed out: https://wiki.mozilla.org/CA:Problematic_Practices

What? Revoking expired certificate is not required, and would be a completely useless thing to do, bloating CRLs for no gain whatsoever.

Sorry, my bad. I wrote 'revoking expired certificates' rather than 'revoking compromised certificates'. Now fixed.

Good question. Maybe you can skip the fee by posting your private key to pastebin and send them the link? :P Might not leave you with an account in good standing with them though ;)

That has been tried before: https://web.archive.org/web/20140412085458/https://revokame....

Hah. So sslip.io should went with Startcom instead of Comodo.

It isn't.

Why? If I own a domain, then declare that "administrators of this domain include: everyone.", then how is the cert invalidly issued?

BTW we love CloudFlare. But the DNS limitations (no wildcards for SSL without $$$$/month, only top-level subdomains allowed) really hurt for developing things. The wildcard bit I understand (valuable service), the multi-level hostnames I don't get; sounds like some technical issue? I know you just get a wildcard for the root, but even paid I've been told there's no workaround. So I can't do [stuff].test.example.com.

    *.example.com won't match foo.bar.example.com. 

That's a technical limitation of the way name matching works (similar to DNS); not a CloudFlare restriction.

Our free Universal SSL certificate includes a wildcard (so if you sign up example.com you get *.example.com).

Annoyingly, TLS wildcards have very a different meaning to DNS wildcards.

DNS wildcards only work when * is the leftmost label of a domain name, so

    *.example.com is a wildcard
    foo.*.example.com is not a wildcard
    *bar.example.com is not a wildcard

A DNS wildcard matches any non-zero number of labels, so

    *.example.com
    foo.example.com matches
    foo.bar.example.com matches
    example.com does not match

RFC 4592 describes DNS wildcards.

Unlike the DNS, the * in a TLS certificate can only match one label, so

    *.example.com
    foo.example.com matches
    foo.bar.example.com does NOT match
    example.com does not match

RFC 2818 also allows the * to appear within a domain name, not just as the leftmost label, and wildcards work even when they are part of a label. One of its examples says

    f*.com
    foo.com matches
    bar.com does not match

But nowadays sub-label wildcards like this are not supported.

Right, but even in paid plans, there's no ability to get further subdomains. Just pointing that out and wondering why. Technical issue that isn't worth the effort?

I contacted one of the founders. The will regroup and solve it hopefully https://twitter.com/briancunnie/status/641258677429628928

Revoked already!

Yes, but the CloudFlare/server leg is unencrypted.

We give customers a certificate signed against our CA to secure the CloudFlare to origin server connection.

You do? Last I checked, I just saw that you had the option to put a self-signed cert on your own server, but no way to tell CloudFlare to validate it (e.g.: I couldn't upload my public cert to CF and say "this is what you should expect"). Alternatively, I could buy my own valid cert and put it on the server. Is the option to get a valid signed cert from CF new?

Did this actually come out?

I've never seen the option in the panel for this, and as far as I know only a handful of users got accepted into the 'beta'.

Hmm, I use your TLS cert but I didn't see the CA-signed one I can use. I'll read the blog post below, thanks.

Cloudflare has a few options you can choose from for cloudflare<=>origin connections. I've tried them all out and they've worked as advertised as far as I could tell:

I set up Cloudflare with their "Strict" SSL option, which requires that my origin servers use a valid TLS certificate. I paid the CA toll to get a cert for my site, and I use that cert to serve connections from Cloudflare's servers.

They also have a "Full" option, which allows you to use a self-signed cert (with no validation -- you might be able to require validation of self-signed certs if you're on a paid plan) on your origin servers, which is slightly more secure than the "Flexible" option, which uses HTTP (with no encryption) when connecting to the origin server, even though it then serves the content to end users over HTTPS with their own (valid) cert.

I use a self signed cert between CloudFlare and my server, I actually couldn't get it to work without doing that, for some reason.