Wonder how long before COMODO revokes this cert?
If you have a test domain you can stick it on CloudFlare and get a certificate for free without the private part becoming public.
> 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.
And check out SSLmate https://sslmate.com/
If the people behind the post used anchor, then the issues mentioned here would be absolved.
Secure Connection Failed
An error occurred during a connection to 52-0-56-137.sslip.io.
Peer's Certificate has been revoked.
It'll be gone in Chrome when the next CRLSet is fetched: https://scotthelme.co.uk/certificate-revocation-google-chrom...
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;
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
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 :)
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 firstname.lastname@example.org.
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.
Our free Universal SSL certificate includes a wildcard (so if you sign up example.com you get *.example.com).
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
example.com does not match
Unlike the DNS, the * in a TLS certificate can only match one label, so
foo.bar.example.com does NOT match
example.com does not match
bar.com does not match
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'.
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.
That's a bad metric. The question is rarely "does this machine use too much swap". The problem comes when performance is degraded because pages that were evicted out to disk are now needed again, and those processes wait for I/O. swapin and swapout are the relevant figures.
edit: (If you're only using 6M of swap, it doesn't really matter, of course. But if a system uses any substantial amount of swap, you want to check rate, not quantity.)
Often times it's better to have a dead system (you do have HA and auto-failover, right?) than to let difficult-to-track-down "slowness" into real time systems.
It's more complicated than just turning off swap. Even without swap, when you run extremely low on memory the page cache will be squeezed to nothing and you'll thrash. And I don't think there's a way to set a minimum page cache on Linux.
So in other words, I would not rely on the OOM killer ever kicking in.
In a situation with more memory use over time a small swap can act as a canary, letting you know you're nearing a performance drop, while a swapless server could suddenly hit a molasses wall without dying.
If you want a canary, why not just directly monitor the page cache size?
Keep in mind that if your swap is not huge, it will very often fill will cold data and you won't have swap thrashing despite running out of memory.
Good point about measuring the page cache directly.
There was a fair amount of interesting engineering to make swap effective.. For example, for the code (text) segment, which was read-only, you'd use the file itself (e.g. a.out) as the swap for the text (code) portion, and if you'd try to `rm a.out` while it was running, you'd get a "text file busy error".
Let's Encrypt began testing their free SSL certificates this week and will formally launch November 16th (two months from now)
However they have no plans for wildcards and you have to renew every 90 days (automation possible).
They also do not have their intermediate certificate working yet (but will have to by November).
But if you do not need wildcards, the StartSSL free certificate has been an option for a long time:
(startssl works in all browsers and has a 1 year renewal)
In fact, the free StartSSL Class 1 DV certificates are only available for non-commercial purposes. They DO enforce this, I have had a cert turned down by their "CertMaster" because they considered it part of a commercial operation.
That is why Let's Encrypt is doubly cool - it is not (at least, in any obvious way) motivated by $$.
They're the best option at the moment if, like me, you don't want want to put a penny in to the CA industry.
On the server side you've to make sure you run a decent nginx/apache with OCSP stapling support. Their responders are slow.
If you're in the market for a certificate I'd jump on board now before it sails, and you're left 'stuck' with whatever automated hoop-jumping crapola Mozilla wheel out in 2 months.
And if you need a wildcard cert, startssl will give you any number of those for just 50$.
I don't think this is a problem for the intended audience - developers and test sites.
But there should perhaps be a clear warning somewhere about not using this in production.
EDIT: Turns out this is actually mentioned on the FAQ page of https://sslip.io/
Confidentiality should be ensured by PFS if the attacker is only sniffing. But so many scenarios where even an unsophisticaded attacker can do more that is is not worth thinking about.
"sslip.io's primary purpose is to assist developers who need to test against valid SSL certs, not to safeguard content."
"Although there's no technical reason why you couldn't use the sslip.io SSL key and certificate for your commerce web, we strongly recommend against it: the key is publicly available; your traffic isn't secure."
This seems like a very silly service to operate, and as remarked by others, I guess the certificate will be revoked soon because the private key data is out there.
Mostly surprised that this wasn't obvious to a company like Pivotal from the first moment.
For testing purposes you can also generate your certs valid only for a few hours/days, so you can be sure they never get used in production by accident. And with proper SAN entries.
In case it helps anyone, I wrote an openssl wrapper with a simple syntax to manage self-signed CAs: https://github.com/radiac/caman
Would you care to elaborate?
They could get a free cert other places, and even look like a real domain.
Coupled with e.g. a XSS vuln on a secured website, you could serve a nasty browser exploiting payload from a secure site, without any warning such as "this page is trying to load stuff from an unsecure site".
This in only one scenario, there are others. This really was pretty bad.
More than having the IP?
SSL is not the place to enforce content restrictions.
Yet another reason why the SSL PKI is a scam and a racket.
It's a tenuous link, but a lot better than no link at all. At times enough for law enforcement to follow the tracks.
(edit since we reached maximum comment depth) Control of an IP address doesn't mean trackable ownership of it, you could use any machine your just compromised and instantly have a valid certificate for it. Delays in certificate issue add a thin layer of security, even if you gained unlegitimate control of a domain, the interval before asking and getting a certificate offers an opportunity for the intrusion to be detected and remediated.
Instant valid certificate for any IP address you happen to compromise is really quite bad.
Why can't you do the same sort of tracking down if you have an IP?
Paying for an SSL cert does make people a bit more accountable, but I'd argue that that's a bug rather than a feature.
I'd love to buy one cert for my main domain and then be able to secure "infinite" depth of subs but every place I've contacted said that doesn't work yet they seem to have done just that...
Your best bet is probably to wait for Let's Encrypt to be generally available, so that you can automatically generate a separate certificate for every hostname.
What's preventing them from resolving YOUR-IP.sslip.io to a completely different IP address that delivers some malware to you?
EDIT: Changed "your users" to "you"
For those interested in rolling your own, we recommend getting your own wildcard certificate and deploying your nameservers: https://github.com/cloudfoundry-community/xip-release#deploy...
In the interim, we plan to see if there's a way we can accomplish what we want without violating the terms of agreement.
Thanks for the interest,