
FFS SSL - jashkenas
http://wingolog.org/archives/2014/10/17/ffs-ssl
======
agwa
The state of things really does suck, and I'm trying to do something about it.

SSLMate [[https://sslmate.com](https://sslmate.com)] sells SSL certs from the
command line for $15.95/year. The sslmate command line tool takes care of
properly generating the key and CSR, and properly assembling the certificate
bundle containing the chain certificate. Certificates secure both example.com
and www.example.com. No more hard-to-use websites or obscure openssl commands.
I'm working on a config file generator too, so you'll be able to specify your
server software and it will output a secure config for you.

And since the author mentioned out-of-process SSL termination, I'm also the
author of titus
[[https://www.opsmate.com/titus/](https://www.opsmate.com/titus/)], an SSL
terminator that is so paranoid it stores the private key in an isolated
process (which would have been impervious to Heartbleed). It also solves the
original IP address problem by using Linux's transparent proxy support - your
web server sees the client's actual IP address even though the connection was
proxied through titus.

~~~
spacefight
Why o why do you charge almost ten times for wildcard certs? A wildcard cert
is technically identical to non-wildcard certs - only one single parameter is
different.

Is it, because you re-sell?

~~~
agwa
Yes, we do resell and that's just how certificate authorities price things.

If you have fewer than 10 hostnames to secure, definitely go with individual
certs and use SNI instead of a wildcard cert. Support for SNI is quite
widespread now, and SSLMate makes managing lots of certs easy.

~~~
lingben
then you are dealing with the wrong resellers! I can buy a wildcard SSL for
$64 RETAIL

[https://www.gogetssl.com/wildcard-ssl-
certificates/](https://www.gogetssl.com/wildcard-ssl-certificates/)

(these guys also have a reseller program but I don't know what that price is)

~~~
iancarroll
Yeah, it sounds like they're in a direct relationship with the CA which only
works when you have $10k+ to front for reasonable rates.

------
Karunamon
I fear SSL isn't going to see wide adoption by normal people until two things
are done:

* It's easier to set up. Having personally been through the situation in the article a time or two in my life, it sucks, and there's no reason for it to suck.

* The prices stop being extortionate. 10x price differential for a literal 1 bit change in the final product to make a wildcard cert? Fuck you! Everyone mentions StartSSL. Sure, the basic certificate is free.. if you don't miskey your domain name.. or you don't select the wrong options.. or OpenSSL doesn't get owned, in which case you get to pay $15 for the privilege of their server spending a few milliseconds of CPU time to spit a few kilobytes of data back at you that represents the thing you already had.

PKI as it exists today is a fucking scam. It's a scam because it's overpriced,
it's a scam because it's exploitative, and it's a scam because it's
_incredibly_ easy to do things that render the whole exercise pointless.

~~~
stevenjohns
Check out CloudFlare, they've been offering free one-click SSL for a little
while now

~~~
gergles
Only if you also agree to give up control over your incoming traffic and DNS
to them. No thanks.

~~~
Karunamon
You "give up control" of your DNS to whoever runs your nameservers.

------
wolf550e
Unless I missed it, article does not say "use
[https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/) to test
your setup", which I think is very useful advice.

Also, you might consider configuring your server to only support cipher suites
that will be supported by TLS 1.3 [0][1] and let old clients get errors. If
you need security, don't use the obsolete stuff the experts don't trust
anymore.

0 -
[https://tlswg.github.io/tls13-spec/#rfc.section.1.2](https://tlswg.github.io/tls13-spec/#rfc.section.1.2)

1 - This means use only (ECDHE|DHE)-(RSA|ECDSA)-AES128-GCM-SHA256 and
(ECDHE|DHE)-(RSA|ECDSA)-AES256-GCM-SHA384. No key exchanges that don't provide
forward secrecy, no RC4, no CBC mode, no MD5, no SHA1.

~~~
AlyssaRowan
You can add (ECDHE|DHE)-(RSA|ECDSA)-CHACHA20-POLY1305 to that too (pretty
soon).

~~~
agwa
This raises an issue that has been troubling me recently. There has been an
explosion in guides that tell you how to secure your TLS installation, and
virtually all of them hard code a cipher list, which I fear won't get
refreshed as better ciphers come out. I've also seen this with recent
instructions to disable SSLv3, which whitelist TLSv1, TLSv1.1, and TLSv1.2,
instead of just blacklisting SSLv2 and SSLv3.

To avoid a situation where future security improvements are held back by
crufty configuration that was added in a well-intended effort to improve
present-day security, I think we should be encouraging blacklists instead; the
OpenSSL cipher list spec actually supports blacklisting.

~~~
aroch
I have a weekly cron that checks my nginx cipher list against Cloudflare's[1].
They're pretty much always first to deploy on new ciphers and they know what
they're doing. And it, for instance, picked up on and reminded me to change
all ~14 of my SSL configs in response to POODLE

[1]:
[https://github.com/cloudflare/sslconfig/blob/master/conf](https://github.com/cloudflare/sslconfig/blob/master/conf)

~~~
agwa
That's a very nice idea.

Of course, you sound like exactly the kind of sysadmin I'm not concerned about
;-)

------
j_s

      tells you how to use StartSSL, which generates the key in your browser. 
      Whoops, your private key is now known to another server on this internet
    

Pardon my ignorance, but I thought the in-browser certificate creation process
avoids sending the private key.

[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/ke...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/keygen)

[http://www.jroller.com/whoami/entry/browser_generated_certif...](http://www.jroller.com/whoami/entry/browser_generated_certificate_requests)
(2006)

~~~
antsar
It does. But what if StartSSL is compromised (or your connection is MITM'ed)
and you're served a page that contains malicious javascript instead of the
intended keygen tag? The only way to be sure would be to check the HTML...in
addition to the rest of the learning curve of implementing SSL.

~~~
RubyPinch
if startssl is compromised (and if start ssl doesn't use ssl, allowing for
mitm), then I don't imagine you'd have much luck regardless

no matter what practices startssl uses, once your connection to them is
compromised or once they are compromised, then the attacker can change what
practices startssl suggests to its users.

~~~
iancarroll
> then the attacker can change what practices startssl suggests to its users.

Or just issue a cert on its own accord...

------
mike-cardwell
The process of adding SSL to a website could be 100% automated.

1.) Start the webserver

2.) Webserver: Oh look, I have a virtual host for example.com but no valid SSL
certificate in order to serve https.

3.) Webserver: Generates a key+cert. Calls out to third party trusted SSL
provider and says: "I control the website for example.com, please sign the
following cert"

4.) SSL provider connects back to example.com to validate that the request for
a cert is authorised, then signs the cert and gives it back.

This could work today, if a trusted third party SSL provider created such an
API and Nginx/Apache were updated to talk to it.

Imagine if next time everyone did an "apt-get dist-upgrade" or a "yum update",
their web servers suddenly started providing a HTTPS version of their site.

[edit] Step 4 is the equivalent of the way domain verified SSL already works
today, except over HTTP rather than Email.

~~~
peterwwillis

      user@host:~$ apt-get install apache2
      
      [...]
      
      Please enter your credit card information to submit your SSL cert request.
    

A company could probably set up an API to allow people to submit/validate CSR
requests via pre-validated profile, but at install time? Nah. There's a lot of
configuration that needs to happen after you install a web server anyway.

And anyway, most websites don't need SSL. Anyone who tells you different is
probably wearing an aluminum foil fashion accessory.

~~~
yourad_io
> And anyway, most websites don't need SSL. Anyone who tells you different is
> probably wearing an aluminum foil fashion accessory.

How about the fact that any HTTP page can be injected with arbitrary
javascript by a MitM? Are you that confident about your browser's
impermeability? Do you always use a VPN in public hotspots? etc.

Anything that's worth viewing, on an often attacked platform (browsers), is
worth viewing securely.

edit: s/link/page/

~~~
peterwwillis
Mitm is still pretty trivial to perform from hotspots, even for supposedly-
https websites. There's a dozen ways I can inject traffic into your browser,
whether on the initial connection to the site you want, or in one of the many
non-https connections from 3rd party content loaded into practically every
website on the internet. This isn't even taking into account the vast number
of attacks on https clients and protocols.

Second, nobody is trying to inject traffic in your browser on a hotspot.
_Nobody._ Nobody cares about your connection. There is no secret cabal of
hackers sitting at every airport and starbucks waiting to steal your Facebook
login. They don't give a shit. You are the tiniest small fry, and they have
much easier ways of committing cybercrime that pay out much better and provide
them better intel.

And yes, if I want to make sure i'm secure, I use a VPN. I assume all public
browsing sessions are hijackable.

------
ef4
> Now you're presented with a bunch of pointless-looking questions like your
> country code and your "organization". Seems pointless, right? Well now I
> have to live with this confidence-inspiring dialog, because I left off the
> organization...

That's not right. Even if you supplied all those details in your CSR, you
would not have solved this problem.

You bought the cheapest kind of certificate. Your "Organizational Unit" says
"Domain Control Validated - RapidSSL". That's all it's ever going to say, no
matter what you put in your CSR. Because the registrar did the bare minimum to
test that you control the domain.

If you want a certificate that says anything more specific than that, you have
to pay more money and provide more proof to the registrar.

------
Pxtl
What flabbergasts me is how much of this is what the gaming world would call
"push this button not to die". That is, it's a question with a right answer
and a wrong answer and no real other options or any reason you'd ever want to
choose the "wrong" option. Intelligent defaults are supposed to take care of
that sort of thing.

~~~
pixl97
Your defaults would change every few months.

BEAST attack comes out... Use RC4.

Not long after.. RC4 is weak use GCM.

GCM isn't supported on older versions of almost everything.

Upgrade servers to 2012R2, latest versions of Linux, throw away your old
phones, check out your legacy devices...

Security isn't a question with a right or wrong answer, it's a question with
the best answer for the available information and the clients you have at the
time. And those answers are changing daily with all the research being
conducted.

~~~
skybrian
All the more reason for someone who's on top of things to fix the defaults
whenever they change.

~~~
pixl97
While that would be nice, it doesn't fix the problem, that problem is

 _If you are administering SSL enabled sites, you MUST keep track of latest
security practices_

Why is that? If you add a new server with different defaults, do you a) update
all the other servers to the new defaults, or b) set the new server to your
existing configuration.

Most server applications don't change defaults between minor versions because
it leads to even worse problems. Such as users not updating because their
application breaks and keeping old bugs alive.

------
michaelbuckbee
It's even worse than that as even if all the above is actually correct and
done perfectly that you may still not get the "green" depending on the browser
as the browser makers are moving to showing domain validated (via email)
certificates as gray and only EV (extended validation) certs as green.

Things to note: EV certs are much more expensive. You cannot get a cert that
is both EV and a Wildcard, single domains only.

Screenshots of how the various browsers show Domain vs EV certs at:

[https://www.expeditedssl.com/pages/visual-security-
browser-s...](https://www.expeditedssl.com/pages/visual-security-browser-ssl-
icons-and-design)

------
michaelmior
> So if you're Google, you friggin add your name to a static list in the
> browser.

It's worth noting that the Chromium project accepts URLs for inclusion into
the bundled list of sites using HSTS. (This is shared with Chrome, Firefox,
and Safari.)

[https://hstspreload.appspot.com/](https://hstspreload.appspot.com/)

------
iancarroll
Few comments:

1) StartSSL doesn't generate it in the browser (on a secure piece of hardware
IIRC), which depending on your viewpoint is good/bad.

2) No CA will allow you to get a 1024 bit cert (you're correct)

3) You should be sending the GeoTrust Global CA cert because it isn't trusted
everywhere, and if it's not sent you'll get errors before you get
SNI/SHA1/SSL3 errors...

4) The "(unknown)" will _always_ occur on FireFox, unless you have an EV
certificate (even OV does not show this)

~~~
kmowery
It's not that the key is generated in Javascript; it's more that the key is
generated (and therefore known) by someone who is not you.

Maybe you trust StartSSL with your private key, maybe you don't, but in either
case not giving them your private key is preferable.

~~~
mappu
It's not... your local web browser generates it by the `<keygen>` element. The
private key never leaves your web browser and is not known to StartSSL.

~~~
geographomics
Just to note that Internet Explorer does this slightly differently, using
VBScript to call the local crypto API as it doesn't support <keygen>. It's
functionally equivalent though.

------
madsushi
With StartSSL, you can actually generate your own key via OpenSSL (and you
should) and then use that instead of doing it in the browser.

~~~
antsar
It is, however, ridiculous that DigitalOcean (a quite popular VPS provider)
advises innocent webmasters to generate it in the browser with no mention of
how insecure this is.

[https://www.digitalocean.com/community/tutorials/how-to-
set-...](https://www.digitalocean.com/community/tutorials/how-to-set-up-
apache-with-a-free-signed-ssl-certificate-on-a-vps)

~~~
Dylan16807
If StartSSL gets hacked you are in a bad place no matter what.

And you're more likely to screw up key safety yourself than for that narrow
window to be exploited.

I don't think it's ridiculous.

~~~
antsar
I agree that there's a very slim chance, realistically, of this being
exploited. But StartSSL doesn't have to be hacked for a user to be MITM'ed and
served malicious JS. Especially given that their site (at least the homepage)
loads over plain HTTP.

------
peterwwillis
It would be pretty frustrating to be dumped onto a highway in a stick shift
and have to learn how to drive by googling for instructions in the car. That
doesn't mean that driving is unnecessarily difficult.

Driving is only intended for people who have been trained and licensed to do
so. Similarly, SSL certs are for people who have been trained on how to
perform the tasks of a server admin, and presumably have read a 10-page ebook
like How To Admin A Web Server.

Web servers in general are never supposed to be touched by the common user.
They never were. Your server admin would set up a user account, and you'd dump
your files in your ~user/public_html/ folder, and maybe if you were super
clever you'd create a .htaccess file. The most complicated task a user ever
was supposed to perform was to run "chmod 755" on the files in their /cgi-bin/
folder on their FTP site. All of this worked because an admin had to set
everything up the right way and know how to do that.

So the next time you take on a technical hurdle you don't understand, I cannot
stress enough how much more useful it is to either look up a good book on how
to do it, or ask someone for help. It may not be as instant-gratification, but
you'll get what you need done faster and understand it better.

~~~
nawitus
>I cannot stress enough how much more useful it is to either look up a good
book on how to do it, or ask someone for help.

Recommending books doesn't seem like a great idea when it comes to web
security, as best practices change so often. Besides, enabling something like
TLS _should_ be easy. The more difficult it's to enable TLS, the less secure
the web will be. In fact, since TLS is so difficult to set up, it's rather
rarely used. If it was easier to set up, it would be more common and the web
would be more secure on average.

~~~
peterwwillis
Well first of all, setting up TLS has not really changed in 15 years. The
protocol has evolved over time, and as a result of wanting the most number of
people to use it as possible, it's not configured by default to be the most
secure; it's designed to be the most compatible. The best practice is to
install it, and then tighten security _to your use case_.

Secondly, 'easy' is 100% subjective. To me it's incredibly easy to set up TLS.
It wouldn't be easy to my grandma. But the same could be said for anything
that takes technical expertise and a complex set of operations. TLS is not
simple, and it will never be simple. People who understand how TLS works know
this already.

------
IgorPartola
Here is my unsolicited and unprofessional advice for this type of site:

1\. Set up HTTPS on every site you run. No, really. That static 10 page info
site for your church group? Yup, get it set up! The no-CSS blog from 1991
(before they were blogs)? Set it up! Even if you don't use WordPress (god,
please tell me you are not running WordPress without SSL), and your site never
lets anyone POST/PUT/DELETE/PATCH to it, remember that what people are reading
is just as important. If I can hijack your site at the local coffee shop and
serve malware, your readers will not be pleased. If I manage to do this in a
widespread fashion, Google/Bing will blacklist your site and nobody will get
to it.

2\. Get a free cert! The dirty secret is that all certs are basically equal
(EV and wildcard notwithstanding, though they are an entirely different
matter). There are at least two places to get decent free certs: StartSSL and
CloudFlare. If you want to protect something but your 10 page church website,
get a cert from Namecheap for $8/year.

3\. Use HTTPS-only. TFA is a great example: it's posted on a blog that can be
accessed by both HTTP and HTTPS. If you leave this configuration, it's almost
as bad as not having HTTPS at all. People don't type in
"[https://..."](https://..."). They go straight to "example.com" or they'll
just Google "example" and click on the first link. Set up your server to
redirect from port 80 straight to the canonical HTTPS version of your site.

If you are unfamiliar with how to set this up: practice. Get a Digital Ocean
box for a few hours ($0.10/hour) and a free cert from StartSSL. Use a random
domain name you own (you'll need a proper second level domain, but chances are
you have one parked somewhere) and try setting up a site. It'll cost you as
much as a single stick of gum and you'll know that much more about how to do
it.

Edit:

4\. Use a strong cipher suite such as this one:
[https://support.cloudflare.com/hc/en-
us/articles/200933580-W...](https://support.cloudflare.com/hc/en-
us/articles/200933580-What-cipher-suites-does-CloudFlare-use-for-SSL-)

5\. Use nginx, at least for front-end proxy. Your life will be easier.

6\. Check your setup against
[https://www.ssllabs.com/ssltest/analyze.html](https://www.ssllabs.com/ssltest/analyze.html).
Fix issues it highlights.

7\. Don't lose your private key. Don't have it live only on the live server.

8\. Use HSTS
([http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security))
but beware that once you have it set, you cannot go back to plain HTTP. For
almost everyone this should not be a problem.

~~~
8_hours_ago
Honest question: is jumping through all the hoops to enable HTTPS really worth
it for a personal static website? Are hijackings really that common? It seems
like a lot of hassle for negligible benefits... plus it's not just a one-time
thing, the best practices seem to change every few months and not following
them can result in "very bad things". It's a heck of a lot easier to just run
HTTP.

~~~
IgorPartola
The first site you ever set up will take you 2-3 hours of screwing around. The
next will take you about 20 minutes. After that, it'll take you 5-10 minutes
per site. If you decide to go with CloudFlare, it'll take a different amount
of time because you'll be setting up DNS through them as well.

It is worth it. Here's why: nobody is going to target your 10-visitors-per-
month site directly. You are right, most people don't care. However, there are
two types of attacks that will get you in trouble. First, where I decide to
sit in a coffee shop and simply hijack every HTTP request. In this case, I am
not targeting you directly, but you are susceptible. Even if you don't care
about that (say, you know that none of your readers are coffee drinkers/public
Wi-Fi users), a much worse situation is where a network attacker is able to
attach a large number of sites hosted with e.g. a specific provider. Let's say
I discover that Digital Ocean has a vulnerability where I can spoof your IP. I
would then MITM all HTTP traffic to all DO hosts, and if you happen to host
with them you are screwed. Note that Google doesn't care whose fault it is:
they blacklist first, ask questions never.

So in short, it takes very little time/money, it's a skill you should have if
you run your own site, and it's warranty against bad things happening.

~~~
8_hours_ago
Has Google ever blacklisted a site due to an attack like that? I see the risk,
I'm just trying to understand how likely it is.

When I first read your scenario about hijacking my site via public wifi, it
didn't strike me as very important... but after thinking about it for a few
minutes, I do see the harm. Even if it's just someone screwing with my resume,
I can envision situations where it could do a lot of harm.

And you do make a good point about the Google blacklist, the consequence of a
Google blacklist is very bad. Even if unlikely, that alone is probably enough
reason to enable HTTPS.

I've set up HTTPS several times on the small sites that I run, and probably
spent about 6 hours on the process in my lifetime. Right after heartbleed came
out, I switched to HTTP only. Now maybe it's time to redo the process and get
it set up again...

~~~
IgorPartola
I've only had a site blacklisted once. My father ran a WordPress blog on
shared hosting and got hacked (probably weak password or vulnerability in one
of the plugins or WP itself, who knows). His site was pretty quickly
blacklisted, and even after he scrubbed it, leaving just a basic index.html
("we are coming back" type thing), it stayed blacklisted for at least several
days. I am sure others have more experience with this, I've just been lucky.

------
yourabi
Yep - getting this right is hard.

Couple of points about the article.

Browsers verify SSL certificates for revocation (OCSP). This is an ongoing
service that has a direct impact on latency - so SSL _is_ an ongoing service
very much like DNS. However, most people don't realize this.

Also you send in a CSR - certificate signing request - not CRT (which is
usually short-hand for certificate).

Also it gets worse - A recent OpenSSL vulnerability would still allow SSLv3
even if it was configured with "no-ssl3":
[https://www.openssl.org/news/secadv_20141015.txt](https://www.openssl.org/news/secadv_20141015.txt)

This is why I built [https://snitch.io](https://snitch.io) \- security and SSL
secured sites in particular are moving targets and not "fire and forget". You
really need an external process monitoring and auditing your secured site.

~~~
function_seven
> Browsers verify SSL certificates for revocation (OCSP). This is an ongoing
> service that has a direct impact on latency - so SSL is an ongoing service
> very much like DNS. However, most people don't realize this.

Inconsistently and sporadically, it seems:
[http://news.netcraft.com/archives/2014/04/24/certificate-
rev...](http://news.netcraft.com/archives/2014/04/24/certificate-revocation-
why-browsers-remain-affected-by-heartbleed.html)

That article is a few months old though. Have Firefox/Chrome changed their
tune due to Heartbleed?

~~~
yourabi
Not really inconsistently. Firefox, Safari and IE all do this. Firefox, for
example, will wait up to 10 seconds for an OCSP response
([https://wiki.mozilla.org/CA:ImprovingRevocation](https://wiki.mozilla.org/CA:ImprovingRevocation))

That article cites Adam Langley - a respected engineer at Google who has
worked on Chrome and parts of Go. Chrome is wildly lax with certificate
revocation. Don't believe me? Browse to
[https://revoked.grc.com](https://revoked.grc.com) from Chrome. It is true
that if someone can MITM they can block CRL/OCSP requests...but browsers
(including Chrome) made the choice of 'soft-failing' and thus making it an
attack vector. OCSP stapling and the proposed "OCSP Must-Staple"
([https://tools.ietf.org/html/draft-hallambaker-
muststaple-00](https://tools.ietf.org/html/draft-hallambaker-muststaple-00))
solve this problem. With all due respect to Adam, it seems a little peculiar
to say revocation checks don't work when they're broken by design in the
browser he worked/works on.

Chrome is the only browser that skips revocation checks for DV certificates
but it still does OCSP for EV certs. Chrome has the concept of CRLsets - but
these have been shown to only capture a very small portion (<1%) of revoked
certificates.

Firefox has the option to hard-fail if the OCSP request isn't verified. This
should be the default behavior, but the fear is that too few people understand
this and would migrate to another browser if SSL secured sites randomly failed
to load sometimes. Note: this is vastly preferable, in my opinion, to loading
a site with a certificate of unknown status.

------
basher
Totally agree with the article, certs are a the biggest money making racket
out there, and a pain in the ass. Certs should be issued with the domain by
default no extra cost.

------
thenduks
It's this kind of thing that gave us such a quick transition to Amazon and
'PaaS' providers becoming ubiquitous. You can avoid all of these problems and
decisions by just giving your various certificates and stuff to ELB or Heroku.

~~~
michaelbuckbee
On Heroku you can use the ExpeditedSSL addon and we will even update the certs
for you as the security standards change.

[https://addons.heroku.com/expeditedssl](https://addons.heroku.com/expeditedssl)

------
deanclatworthy
A great write-up on the problems associated with getting https up and running.
It's no wonder huge swaths of the internet are unsecured. I recently had to
set up SSL for a Facebook app at work, and jump through a lot of these hoops
(whilst missing some too it seems).

So my question to HN is: What is being done to simplify this process and make
it a simpler, more user-friendly process? (other than what Cloudflare have
done).

------
nichochar
I installed SSL for my company's website last week (i'm a decent backend
engineer and unix hacker). It BLEW my mind how difficult it was for me to: 1)
understand the problem 2) find the best certificate issuer 3) make the
wildcard work

I 100% understand what happened to you and why you wrote this, and frankly I
think someone should fix this. There's room for a great service here in my
opinion

------
rll
I still like StartSSL better than the other options. Yes, obviously opt out of
having them generate your private key and CSR and upload your own. There is a
big obvious "skip this" button there for that. To me the killer feature is
that with class 2 validation ($60/year) you can generate as many 2-year certs,
_including wildcard_ as you want.

------
kbuck
Configuring things is hard, and if you rely on Google to give you magic
commands to execute instead of learning about what you're doing, you can
really mess up.

If you don't have the time to spend properly administrating a system, don't do
it; use a hosted platform so that someone else (who knows what they're doing)
does it for you.

------
ochoseis
I ran into issues deploying HTTPS this past week. Two things of note:

\- Android is super strict with certificates...make sure you properly order
your server and intermediates

\- Check your site on:
[https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/). This
helped me solve a lot of issues

------
Fizzadar
This post speaks hits the spot - a perfect rundown of the (broken) SSL
experience. Why do we still live in an age where security & identity are so
tightly bound that to "secure" a site, you have to _pay_ someone to "validate"
your authenticity - which we all know, is bollocks anyway.

------
bensedat
If you'd like to test your SSL config against POODLE, we've updated our tester
([https://www.tinfoilsecurity.com/poodle](https://www.tinfoilsecurity.com/poodle))
to call out unsafe ciphers.

------
pja
You can get StartSSL to sign a CSR that you generate locally, or at least you
could when I generated the cert for my site with them.

This the only nitpick I have with this otherwise fine rant. Everything is
broken, rejoice!

------
claar
No need for that word in the headline.

~~~
IvyMike
Note for clarity: claar's complaint was prior to a headline edit; "FFS" used
to say "For Fuck's Sake".

~~~
Zikes
Which was undoubtedly changed to more closely match the actual article title,
rather than for censorship/family-friendliness reasons.

------
evandena
Sounds like you should be using Blogger or some other hosted platform.

------
ibebrett
Honestly, this task is something that most people learn to do and just do.
It's not nearly as complex as you are trying to a make it out to be.

------
kokey
It could be worse, he could have googled how to do something in php.

