WoSign: Free two-year multi-domain SSL certificate(ohling.org)
ohling.org
WoSign: Free two-year multi-domain SSL certificate
https://www.ohling.org/blog/2015/02/wosign-free-2y-ssl-certificate.html
13 comments
You're completely right, and up voted because THIS IS AN SHA1 CERTIFICATE, IT WILL TRIGGER BROWSER WARNINGS, YOU DONT WANT IT should remain the top post, but David Cameron did actually win an election and is currently the Prime Minister of the UK.
In the spirit of your most thorough pedantry, I thought I'd correct your correction to say that OP is right, David Cameron didn't win an election, he won a seat as an MP.
None of the parties achieved the 326 seats required for an overall majority under the First Past the Post system. The Conservatives won the largest number of votes and seats but under FPTP rules were 20 seats short.
None of the parties achieved the 326 seats required for an overall majority under the First Past the Post system. The Conservatives won the largest number of votes and seats but under FPTP rules were 20 seats short.
Good point. Such a pity the conservatives elect their own leader with preferential voting but campaigned against the public doing the same.
Because it was designed to give undue influence to fringe parties. Real electoral reform would be proportional representation.
Do you have a reference for that? Is Australia trying to give undue influence to fringe parties? Are the conservatives trying to promote fringe candidates?
In a leadership election, it's in their interest to have a clear winner with a large majority. In a general election, it's in nobody's interest and indeed, counter to the national interest to have a huge majority.
In a general election, a leader that most people find acceptable is preferable to a leader that most people do not find acceptable.
Or at least electoral boundaries that didn't unfairly benefit Labour
[deleted]
They also offer SHA2; only their intermediate cert is SHA1.
…and they've signed their own certificates with SHA-1 because…?
...because in China pre-SP3 Windows XP is still alive and doesn't work with SHA2
Not the kind of security decision I want to see a CA make!
Which underlies the problems with PKIX: any CA can sign anything, just about. Lowest common denominator. I actually prefer DNSSEC there myself - yes, yes, I know, hear me out for a moment! - because even if it's hierarchical, it's single hierarchical from those who are supposed to control the DNS anyway. (Of course, that still introduces points of attack. It's reasonable for countries to control ccTLDs but I wouldn't mind seeing IANA control the others under international law. And it doesn't really do it very well.)
In practice both have big flaws, but at least one can be used to pin the other so the benefits of both can be realised. Distributed systems may win in the end, but we're only at the start of that journey.
Which underlies the problems with PKIX: any CA can sign anything, just about. Lowest common denominator. I actually prefer DNSSEC there myself - yes, yes, I know, hear me out for a moment! - because even if it's hierarchical, it's single hierarchical from those who are supposed to control the DNS anyway. (Of course, that still introduces points of attack. It's reasonable for countries to control ccTLDs but I wouldn't mind seeing IANA control the others under international law. And it doesn't really do it very well.)
In practice both have big flaws, but at least one can be used to pin the other so the benefits of both can be realised. Distributed systems may win in the end, but we're only at the start of that journey.
So... they manage to get the lowest denominator of SHA1 and SHA2 (which will probably remain SHA1 forever, but still...) -- because it'd be enough to compromise only one of these?
> great free StartSSL
It looks like they cleaned up their forums from when they were last mentioned[1] but I'll still keep my distance.
Anything like this is really a bandaid for the real problem with SSL/CA. As in why can't I be a CA for my own domain? I think Android is a perfect example of this problem - if you import a CA cert using the built in Android credential storage every time you reboot it will show a vague and useless message saying that people may be spying on you. Not which CA cert was added and when - just "hey, you added, on purpose, a CA cert. I'm just making sure you are aware of this".[2] I understand the warning? error?...err simply because now I can sign a cert for ANY domain and Android will accept it as legit. This makes sense for the average users who don't understand or care what a CA is, not advanced users or enterprise users who will most likely use their own CA infrastructure. In this case - it would make more sense for them to be a CA over just company.tld rather than any domain.
Personally - I'm using a modified version of PHP-CA[3] (as in changed the OpenSSL defaults to something sane and fixed some small issues). It's obviously not very advanced (for lack of better words kind of sucks) - but I wanted to hit the ground running with being my own CA for personal use and I have other projects I'm working on.
[1] - https://news.ycombinator.com/item?id=8901822
[2] - https://code.google.com/p/android/issues/detail?id=82036
[3] - http://php-ca.sourceforge.net/
It looks like they cleaned up their forums from when they were last mentioned[1] but I'll still keep my distance.
Anything like this is really a bandaid for the real problem with SSL/CA. As in why can't I be a CA for my own domain? I think Android is a perfect example of this problem - if you import a CA cert using the built in Android credential storage every time you reboot it will show a vague and useless message saying that people may be spying on you. Not which CA cert was added and when - just "hey, you added, on purpose, a CA cert. I'm just making sure you are aware of this".[2] I understand the warning? error?...err simply because now I can sign a cert for ANY domain and Android will accept it as legit. This makes sense for the average users who don't understand or care what a CA is, not advanced users or enterprise users who will most likely use their own CA infrastructure. In this case - it would make more sense for them to be a CA over just company.tld rather than any domain.
Personally - I'm using a modified version of PHP-CA[3] (as in changed the OpenSSL defaults to something sane and fixed some small issues). It's obviously not very advanced (for lack of better words kind of sucks) - but I wanted to hit the ground running with being my own CA for personal use and I have other projects I'm working on.
[1] - https://news.ycombinator.com/item?id=8901822
[2] - https://code.google.com/p/android/issues/detail?id=82036
[3] - http://php-ca.sourceforge.net/
You're right that SSL has problems, but you cannot be the certificate authority for your own domain, and I'll explain why.
The certificate authority system is an imperfect solution for the problem of public key infrastructure. It is designed such that a trusted, independent third party can verify messages between two communicating parties. The third party's trusted signature verifies that the user is who they say they are.
Now, if anyone can be a certificate authority, and you can be your own certificate authority, you have effectively removed certificate authorities entirely - you now end up with de facto two parties. This is convenient for you to certify that you are yourself, obviously.
This is inconvenient and dangerous for you when anyone else certifies that they are you using themselves as a certificate authority - if they can sign their public key using their own nominal trustworthiness, the entire problem is back where it started without the certificate authorities in the first place.
By design, certificate authorities need to be 1. trustworthy, 2. highly vetted and 3. very few. If everyone is a certificate authority, then no one is.
The certificate authority system is an imperfect solution for the problem of public key infrastructure. It is designed such that a trusted, independent third party can verify messages between two communicating parties. The third party's trusted signature verifies that the user is who they say they are.
Now, if anyone can be a certificate authority, and you can be your own certificate authority, you have effectively removed certificate authorities entirely - you now end up with de facto two parties. This is convenient for you to certify that you are yourself, obviously.
This is inconvenient and dangerous for you when anyone else certifies that they are you using themselves as a certificate authority - if they can sign their public key using their own nominal trustworthiness, the entire problem is back where it started without the certificate authorities in the first place.
By design, certificate authorities need to be 1. trustworthy, 2. highly vetted and 3. very few. If everyone is a certificate authority, then no one is.
> By design, certificate authorities need to be 1. trustworthy, 2. highly vetted and 3. very few. If everyone is a certificate authority, then no one is.
Isn't that the situation we are in now? All it takes is one CA with poor security coughDiginotarcough and the whole system is broken. I'm obviously ignoring the fact we have CRLs - but if someone has a signed cert for say chase.com or google.com they can do a lot of damage in a very little amount of time.
Maybe I'm just cynical that there is a profit motive to CAs. I mean, you can't tell me that it's just greed that you can purchase a certificate to turn a user's address bar green because it's "extended validated". The average user won't notice, or even know what that means. Big picture behavior - there is no functional difference between a EV and non-EV signed certificates.
My opinion: if we keep the SSL/CA system the way it is today - we need fewer CAs but create non-profit CAs where the average person can get CA signed/trusted certificate for free or next to free. I'm not talking about grabbing some random dude off the street and start a non-profit - it should be funded and sponsored by companies like Google/Verisign/Microsoft etc.
Isn't that the situation we are in now? All it takes is one CA with poor security coughDiginotarcough and the whole system is broken. I'm obviously ignoring the fact we have CRLs - but if someone has a signed cert for say chase.com or google.com they can do a lot of damage in a very little amount of time.
Maybe I'm just cynical that there is a profit motive to CAs. I mean, you can't tell me that it's just greed that you can purchase a certificate to turn a user's address bar green because it's "extended validated". The average user won't notice, or even know what that means. Big picture behavior - there is no functional difference between a EV and non-EV signed certificates.
My opinion: if we keep the SSL/CA system the way it is today - we need fewer CAs but create non-profit CAs where the average person can get CA signed/trusted certificate for free or next to free. I'm not talking about grabbing some random dude off the street and start a non-profit - it should be funded and sponsored by companies like Google/Verisign/Microsoft etc.
I agree with everything you've said here. Certificate authorities are, like all organizations, prone to corruption and misaligned incentives. There are certainly issues, and it's very much an imperfect solution. The trouble is that getting rid of them (right now) is a net loss for cryptographic integrity. SSL, and perhaps public key infrastructure underpinning it, needs to be redesigned. There is no viable alternative just yet.
Or better, cut out Verisign completely out of this... correct me if I am wrong but if the major browser vendors: Microsoft, Google, Apple, Opera, and Mozilla come together can't they basically decide to cut off any certificate authority as they wish? Can't they basically tell Verisign to issue certificates for free of cost or get booted out?
The only reason why I suggested Verisign is because they have been in the industry long enough to know what they are doing (presumably) and not make the same mistakes that were made in the past.
Worst case scenario - if Verisign doesn't want to share the toys in the sandbox, Microsoft/Google/Mozilla et all can just refuse to include their CA certs as trusted certs.
However, Verisign is in a very interesting position as they currently manage/control .com tld.
So what I'm saying is - if the children don't agree to play together then they can take their toys and go home then no one can play.
(I like to use the analogy of children and these big companies because, in my opinion, it appears that's how they operate. They just can't come together, like mature adults, and form some sort of solution to this. Last I heard is that Google wants to show an error page for non-HTTPS enabled sites, on Chrome, which will make everything even worse[1]. Don't even get me started on the whole self-signed cert error message page...).
[1] - http://www.chromium.org/Home/chromium-security/marking-http-...
Worst case scenario - if Verisign doesn't want to share the toys in the sandbox, Microsoft/Google/Mozilla et all can just refuse to include their CA certs as trusted certs.
However, Verisign is in a very interesting position as they currently manage/control .com tld.
So what I'm saying is - if the children don't agree to play together then they can take their toys and go home then no one can play.
(I like to use the analogy of children and these big companies because, in my opinion, it appears that's how they operate. They just can't come together, like mature adults, and form some sort of solution to this. Last I heard is that Google wants to show an error page for non-HTTPS enabled sites, on Chrome, which will make everything even worse[1]. Don't even get me started on the whole self-signed cert error message page...).
[1] - http://www.chromium.org/Home/chromium-security/marking-http-...
> trustworthy
Do you really trust all of these keys?
https://www.mozilla.org/en-US/about/governance/policies/secu...
Even companies like AOL, VISA, Wells Fargo, and the historically-problematic VeriSign and GoDaddy, and lets not forget the Even the companies with serious legal issues in the past, and several governments (China, Japan, Turkey, etc).
This reliance on a single point of trust is why the PKI systemd is destined to fail in the long run: that single point of trust also a single point of failure. The entire concept of a CA requires handing over key parts of our infrastructure over to a small list of "authorities" (which grants the CA a lot of power), while simultaneously trusting those authorities to never abuse that power or be corrupted from the outside.
> If everyone is a certificate authority, then no one is
This is actually the core problem with PKI. Not only does it presuppose that a "few" trusted authorities is even possible, it also frames the discussion by assuming that only a globally supported solution is required. This attitude also dismisses the capabilities to evaluate trust and merely asserts that most people shouldn't worry about this kind of security problem.
A better idea is to recognize that everybody solves pieces of the trust problem constantly in their daily life. Some of the decisions are made of personal experience or observation, but we also rely on others that we see as an "authority". These are powerful behaviors that should be built upon. Everybody can be a CA, because they already are in.
Someone that sets up an "authority" that is only used between a group of friends is perfectly safe IFF 1) stays at the scale where trust already exists, AND 2) the people involved have some easy way to select the trust basis they wanto to use.
Criteria 2 is the most important. The CA system is de facto boolean trust. (i.e. HTTP-vs-HTTPS). There is no sane way for the typical user to say they want, for any particular transaction or communication, to only trust some specific authority (or authorities). and then switch to a completely different trust basis as needed. Once this ability is in the hands of the average person, I suspect the key distribution problem will solve itself as people self-organize.
Do you really trust all of these keys?
https://www.mozilla.org/en-US/about/governance/policies/secu...
Even companies like AOL, VISA, Wells Fargo, and the historically-problematic VeriSign and GoDaddy, and lets not forget the Even the companies with serious legal issues in the past, and several governments (China, Japan, Turkey, etc).
This reliance on a single point of trust is why the PKI systemd is destined to fail in the long run: that single point of trust also a single point of failure. The entire concept of a CA requires handing over key parts of our infrastructure over to a small list of "authorities" (which grants the CA a lot of power), while simultaneously trusting those authorities to never abuse that power or be corrupted from the outside.
> If everyone is a certificate authority, then no one is
This is actually the core problem with PKI. Not only does it presuppose that a "few" trusted authorities is even possible, it also frames the discussion by assuming that only a globally supported solution is required. This attitude also dismisses the capabilities to evaluate trust and merely asserts that most people shouldn't worry about this kind of security problem.
A better idea is to recognize that everybody solves pieces of the trust problem constantly in their daily life. Some of the decisions are made of personal experience or observation, but we also rely on others that we see as an "authority". These are powerful behaviors that should be built upon. Everybody can be a CA, because they already are in.
Someone that sets up an "authority" that is only used between a group of friends is perfectly safe IFF 1) stays at the scale where trust already exists, AND 2) the people involved have some easy way to select the trust basis they wanto to use.
Criteria 2 is the most important. The CA system is de facto boolean trust. (i.e. HTTP-vs-HTTPS). There is no sane way for the typical user to say they want, for any particular transaction or communication, to only trust some specific authority (or authorities). and then switch to a completely different trust basis as needed. Once this ability is in the hands of the average person, I suspect the key distribution problem will solve itself as people self-organize.
As in why can't I be a CA for my own domain?
Because then anyone who can hijack DNS for your domain can also be a CA for your domain.
Because then anyone who can hijack DNS for your domain can also be a CA for your domain.
I'm sorry I didn't make that more clearer - that was a hypothetical question. The question is a loaded question and it raises other deeper rooted issues like what you pointed out (MITM attacks against DNS being one such example).
There would have to be some sort of authoritative list where it says "this CA cert can sign certificates only for this domain". However, such a system I described would basically be CAs as they currently stand. The question/problem is who would maintain such a list? This is hard question considering we can't even agree on web standards coughMicrosoftcough.
There would have to be some sort of authoritative list where it says "this CA cert can sign certificates only for this domain". However, such a system I described would basically be CAs as they currently stand. The question/problem is who would maintain such a list? This is hard question considering we can't even agree on web standards coughMicrosoftcough.
Is that any worse than what we have now? If I can hijack your DNS, I can certainly insert or replace enough infrastructure to acquire a basic cert from numerous providers. All I really need is to hijack the MX. Bonus points if I can do it without you knowing, such that mail is first delivered to me and then on to you.
In other words, if you could put a CA into a TXT record at the root of the domain and have browsers/etc trust it, how is it any less secure than what we have now?
In other words, if you could put a CA into a TXT record at the root of the domain and have browsers/etc trust it, how is it any less secure than what we have now?
The scenario you've described leaves an audit trail. If you don't have a CA, hijacking the DNS means you can pull off an attack completely silently.
Seems they just recently passed Mozilla's/Google's CA root inclusion process: https://bugzilla.mozilla.org/show_bug.cgi?id=851435
Edit: Hmm, looks like the free certs will never pass strict OCSP checks. As broken as the OCSP system is, I would still like to be able to check against it.
Edit: Hmm, looks like the free certs will never pass strict OCSP checks. As broken as the OCSP system is, I would still like to be able to check against it.
Usually it's quite easy to pass this (a single vendor) - you just need to get verified by a WebTrust recognized company (E&Y or some other bookkeeping company) and be able to convince the vendor (the process is pretty much the same with each vendor).
However you'll need to build and run your infrastructure upfront so you're already burning some years money just to get those documents. When you finally get them and become ready to apply for inclusion with the vendors (Apple/MSFT/GOOG/Mozilla/Debian etc) it will take another couple of months. Even when you're included there is a big chance that it will take a couple of years to reach a high enough distribution rate to be acceptable for business purposes (think of old android devices or Windows XP).
Getting cross-signed by another CA costs money and they will re-validate your setup as you will sign "below" their root CA.
I wonder what the total initial and running costs of starting up a CA (including WebTrust & yearly re-audit) are today...
However you'll need to build and run your infrastructure upfront so you're already burning some years money just to get those documents. When you finally get them and become ready to apply for inclusion with the vendors (Apple/MSFT/GOOG/Mozilla/Debian etc) it will take another couple of months. Even when you're included there is a big chance that it will take a couple of years to reach a high enough distribution rate to be acceptable for business purposes (think of old android devices or Windows XP).
Getting cross-signed by another CA costs money and they will re-validate your setup as you will sign "below" their root CA.
I wonder what the total initial and running costs of starting up a CA (including WebTrust & yearly re-audit) are today...
> apply for inclusion with the vendors (Apple/MSFT/GOOG/Mozilla/Debian etc) it will take another couple of months
Mozilla takes ~1.5 years to include a CA.
> I wonder what the total initial and running costs of starting up a CA (including WebTrust & yearly re-audit) are today...
Without including man-hours, I've estimated it to be $550k for creating and maintaining a CA for three years. The audits make up a large majority of this. Big firms like E&Y charge a lot, which is what my estimate is based off of. You also need HSMs + places to store the HSMs, a CP(S), etc. If you've ever read the WebTrust guidelines, you'll know you need a lot of accountability and security.
You could probably reduce the figure with a small auditing firm. My estimates of course are estimates. Certly got quoted $120k/yr (not including a readiness audit) for a WebTrust audit by E&Y.
Mozilla takes ~1.5 years to include a CA.
> I wonder what the total initial and running costs of starting up a CA (including WebTrust & yearly re-audit) are today...
Without including man-hours, I've estimated it to be $550k for creating and maintaining a CA for three years. The audits make up a large majority of this. Big firms like E&Y charge a lot, which is what my estimate is based off of. You also need HSMs + places to store the HSMs, a CP(S), etc. If you've ever read the WebTrust guidelines, you'll know you need a lot of accountability and security.
You could probably reduce the figure with a small auditing firm. My estimates of course are estimates. Certly got quoted $120k/yr (not including a readiness audit) for a WebTrust audit by E&Y.
At risk of sounding xenophobic, you have to wonder if this is simply an effort to have Chinese-issued certificates become common place in the west. A common form of certificate pinning is based on the CA that issued the certificate (to allow certificate rotation). More Chinese issued certificates being used intentionally will make the mere fact that a certificate was issued by a Chinese CA less suspicious.
Yes and no.
Nothing is 100% secure and new CA players will bring a higher encryption usage overall (in this case -> other business model/regional reach). Higher usage will also drive the amount of criminals (including secret agencies) trying to MITM/intercept those encryption. This will push vendors and developers to increase certificate pinning and other models of "bottom-up" models besides the top-down model that the CA-model implements.
IMHO it would be great to have a "working by default" model (which the CA-model is compared to something like pgp) and a protocol-independent way to pin public keys (eg not tied to http/s like HSTS and HKPK).
People and companies in need of "higher" security can pin keys and eg ignore the root trust of their OS/browser. So IMHO the best of "both" worlds.
HSTS http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
HPKP https://developer.mozilla.org/en-US/docs/Web/Security/Public...
Nothing is 100% secure and new CA players will bring a higher encryption usage overall (in this case -> other business model/regional reach). Higher usage will also drive the amount of criminals (including secret agencies) trying to MITM/intercept those encryption. This will push vendors and developers to increase certificate pinning and other models of "bottom-up" models besides the top-down model that the CA-model implements.
IMHO it would be great to have a "working by default" model (which the CA-model is compared to something like pgp) and a protocol-independent way to pin public keys (eg not tied to http/s like HSTS and HKPK).
People and companies in need of "higher" security can pin keys and eg ignore the root trust of their OS/browser. So IMHO the best of "both" worlds.
HSTS http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
HPKP https://developer.mozilla.org/en-US/docs/Web/Security/Public...
Honestly I'd like to see something in the vein of TACK [1] over the other various key pinning methods.
[1]http://tack.io/
[1]http://tack.io/
Agreed. This plus Certificate Transparency (Google) will go a really long way.
http://blog.okturtles.com/2014/09/the-trouble-with-certifica...
Disclaimer: okTurtles is a competitor to the traditional CA system.
Disclaimer: okTurtles is a competitor to the traditional CA system.
That's really neat.
I just thought my past employee (used to have StartSSL but got rejected recently) have to buy an wildcard one for a year while "Let's Encrypt" is not yet here, but this is just great. Will tell them to save their money.
Hope they'll update MAC soon. Wonder if they have an option to sign only for an year, so expiry date won't get past 2017. SHA1 should suffice for an year.
I just thought my past employee (used to have StartSSL but got rejected recently) have to buy an wildcard one for a year while "Let's Encrypt" is not yet here, but this is just great. Will tell them to save their money.
Hope they'll update MAC soon. Wonder if they have an option to sign only for an year, so expiry date won't get past 2017. SHA1 should suffice for an year.
I wonder if they provide an easy way to revoke and re-issue a certificate, too. Probably not.
Yes they do.
Support free reissue and CRL: https://www.wosign.com/english/DV_KuaiSSL.htm
And there is a revoke & reissue button in the control panel, though I haven't tried myself.
And there is a revoke & reissue button in the control panel, though I haven't tried myself.
This offer sounds great!
However, I must ask -- what's their business model?
Even as great as the offer is, this is akin to the free sample... Because once you deploy the https:// address scheme, there is no going back. On the other hand, this would have been perfect if there was opportunistic encryption within HTTP.
However, I must ask -- what's their business model?
Even as great as the offer is, this is akin to the free sample... Because once you deploy the https:// address scheme, there is no going back. On the other hand, this would have been perfect if there was opportunistic encryption within HTTP.
State-sponsored CA perhaps?
I'd be a little suspicious of anything too free like that. I hate to be too xenophobic but I can't say the thought didn't cross my mind.
I'd be a little suspicious of anything too free like that. I hate to be too xenophobic but I can't say the thought didn't cross my mind.
> Because once you deploy the https:// address scheme, there is no going back.
Unless you send the HSTS header, that's not true. Even so, you could just set the HSTS expiry time to the certificate's expiry (which would have to be done within your code, sadly).
Unless you send the HSTS header, that's not true. Even so, you could just set the HSTS expiry time to the certificate's expiry (which would have to be done within your code, sadly).
What do you mean it's not true without HSTS? Do modern browsers now automatically switch to the http:// address scheme if https:// is no longer available?
Because otherwise, unless you don't care about incoming links, bookmarks etc, there is indeed absolutely no going back, with or without HSTS. That's the problem, only solvable with opportunistic encryption.
And if you have dozens of domains and subdomains, what would you do in 2 years if this only CA is then kaput? The value of their offering is definitely above 100 USD, it would appear.
Because otherwise, unless you don't care about incoming links, bookmarks etc, there is indeed absolutely no going back, with or without HSTS. That's the problem, only solvable with opportunistic encryption.
And if you have dozens of domains and subdomains, what would you do in 2 years if this only CA is then kaput? The value of their offering is definitely above 100 USD, it would appear.
EFF is going to be giving out free certs starting later this year. https://letsencrypt.org/ It's not too surprising someone would lower prices now to adjust.
This is becoming a freemium product.
This is becoming a freemium product.
>Before you stop reading because you don't trust a Chinese company for your website encryption please keep in mind that you don't have to trust them at all! You generate the SSL key on your server and only send them the CSR (certificate signing request) which doesn't contain any private information.
That's not really the reason we might not trust a CA. The CA needs to make assurances that it won't improperly sign certificates for an entity purporting to be the principal, e.g., DigiNotar. Maybe this CA has, but that's still a weak argument.
That's not really the reason we might not trust a CA. The CA needs to make assurances that it won't improperly sign certificates for an entity purporting to be the principal, e.g., DigiNotar. Maybe this CA has, but that's still a weak argument.
I don't get your DigiNotar reference; they were hacked; how is that different from any other CA that got hacked?
DigiNotar failed to disclose the known breach for 6 weeks (https://blog.mozilla.org/security/2011/09/02/diginotar-remov...) Whether it was incompetence, coercion, or complicity matters little. I still have my doubts that China provides a climate suitable to a properly functioning CA.
In case you missed it: this is SHA 1, and will trigger browser warnings because it's considered insecure.
Nice find! But given the amount of hassle to get one, your hourly rate must be very low. But I'm sure it will be the future to get near-0$ DV-certificates.
It's a pity no CA besides StartCom and Comodo pick up the S/MIME market. Both options are not very usable for non-IT people.
It's a pity no CA besides StartCom and Comodo pick up the S/MIME market. Both options are not very usable for non-IT people.
> It's a pity no CA besides StartCom and Comodo pick up the S/MIME market.
A lot of CAs sell S/MIME certs, including GlobalSign and CyberTrust. They're not heavily advertised, though.
A lot of CAs sell S/MIME certs, including GlobalSign and CyberTrust. They're not heavily advertised, though.
Cloudflare offer free SSL now, so if you are small and can't afford a certificate, they could be a good choice.
Cloudflare Univeral SSL uses SNI https://support.cloudflare.com/hc/en-us/articles/203041594-W...
Sure, but looking at:
Current inclusion status in major CA certificate stores:
Included by default in NSS 3.16.3 or newer (Mozilla Firefox 32+).
Included by default in Microsoft Windows since September 2014 on Windows Vista+ (should automatically update as mentioned here).
Included by default in Android 5.0+ (no source, but on my Nexus tablet with Android 4.4.4 it is not yet included but on my Nexus phone with Android 5.0 it is)
It is not yet included in the Apple certificate store. This is not a big issue however, since the WoSign root CA is cross-signed by the StartCom CA which itself is included almost everywhere since >5 years.
SNI isn't included in Windows XP, yet the SSL won't work in XP anyway.
SNI isn't included in Windows XP, yet the SSL won't work in XP anyway.
S/MIME != SSL
http://en.wikipedia.org/wiki/S/MIME
Yes, that would be @ https://en.wikipedia.org/wiki/S/MIME (ffs, lol; we're talkin' about SSL :))
No we were talking about X509 certificates
update: WoSign now has a new page https://buy.wosign.com/free/ which is in English, works without creating a account first and wraps up all the steps in one simple page.
The issue with "Submit request contains invalid data" some people ran into was fixed as well :)
Anyone else is getting "提交请求中,包含非法数据" (Submit request contains invalid data) after completing all the steps?
yea,i also can't get it to work. been bashing my head against this for hours. i did this to make the multidomain cert: http://stackoverflow.com/a/9158662/4202492[1]
then i'm doing this: "openssl req -out example.com.csr -new -sha256 -newkey rsa:2048 -nodes -keyout example.com.key -config openssl.cnf"
do i need to attach a mail adress to the csr? do i need to set a challenge password? what is the "free binding domain" on wosign?
do i need to attach a mail adress to the csr? do i need to set a challenge password? what is the "free binding domain" on wosign?
Stolen right off of LowEndTalk.
The objective truth is that no theft has happened. Laws about theft are not applicable to copyright infringement.
But you're right, it's taken from LowEndTalk[1] and it remains unknown to us if the author asked for permission to copy the instructions to his or her blog.
[1]: http://www.lowendtalk.com/discussion/41289/free-chinese-2-ye...
But you're right, it's taken from LowEndTalk[1] and it remains unknown to us if the author asked for permission to copy the instructions to his or her blog.
[1]: http://www.lowendtalk.com/discussion/41289/free-chinese-2-ye...
Yep, I have full permission do use the instructions :)
Remember, unless you're pinning your certificate using DNSSEC+DANE or HPKP, in practice any CA in the world can issue certificates for any domain.
Let's recap: It's 2015. They're using SHA-1 for everything (NOOOO!). They're based in China, which has just said it wants to ban encryption. (So has Cameron in the UK, yes, but at least he hasn't won an election yet. Edit: he pledged to if he wins; we have a coalition government, nobody won last time, least of all us! <g>) It looks like they've messed up OSCP, so even their own cert doesn't pass. Oh, and RC4, TLS 1.0 only, check out their login server: https://www.ssllabs.com/ssltest/analyze.html?d=login.wosign.... - let's put the (slightly) stronger ones at the end, everyone! Ugh.
Let's Encrypt will do it properly. Or Else™. ;)