
Ask HN: How bad is it to use a self-signed SSL certificate? - mark_l_watson
I have a few &quot;information only&quot; (i.e., no customer data stored, no user logins) for almost 20 years that I just added HTTPS support for.<p>I did this after reading the EFF&#x27;s &quot;Join us on June 5th to Reset the Net&quot; article and the two linked articles at the bottom of the page.<p>If any accesses my sites with HTTPS, they have to look at my certificate and OK it. A pain.<p>Ask HN: How bad is it to use a self signed SSL certificate?<p>Also, suggestions for the cheapest&#x2F;easiest ways to get signed certificates?<p>BTW, I used this article for configuring nginx for SSL: https:&#x2F;&#x2F;www.digitalocean.com&#x2F;community&#x2F;articles&#x2F;how-to-set-up-multiple-ssl-certificates-on-one-ip-with-nginx-on-ubuntu-12-04
======
ctz
If you are careful when generating your certificate (that is, careful to
generate a subject certificate, and not a CA certificate) and _can reliably
distribute your certificate to all clients you are interested in_ , then self-
signed certificates are usually _much better than the public CA system_.

But actually achieving the pre-distribution step is pretty hard, and basically
impossible over the internet. You can achieve it pretty well in a business
setting, where you can push your certificates to all the clients through AD,
MDM, or similar.

Sidenote: You should also take this opportunity to appreciate how dismally
mis-designed web transport security is:

* Cleartext, unauthenticated: just works, no warnings.

* Encrypted, unauthenticated: THE SKY IS FALLING.

* Encrypted, authenticated: little padlock.

~~~
tptacek
A site claiming to offer cryptographic security when it is in fact not is, in
reality, worse than a site that simply doesn't offer cryptographic security.
Both those sites --- the SSL site and the non-SSL site --- aren't offering
security. But only one of them is also being deceptive about it.

However, you'll get no argument from me if you constrain your argument about
dismal mis-design to browser UI/UX. The browser UX design for TLS security
hasn't meaningfully changed since Netscape.

~~~
mindslight
Unauthenticated SSL does provide security against _passive attackers_ , which
is what mass surveillance in developed countries is. If the NSA ever insists
on widespread MITM of connections, we have much bigger problems.

I agree the UI needs to be properly worked out so that eg a bank can't be
downgraded to an unauthenticated certificate.

~~~
chimeracoder
I don't understand why they don't just use different colors for self-signed
SSL connections.

CA-signed: Green lockpad

Self-signed: Yellow lockpad, with question mark superimposed over it

Regular HTTP: Orange, no lockpad (insecure)

Invalid or revoked cert: Red, "stay away" displayed within <blink> tags.

The current UI that most browsers present implies that self-signed
certificates are _worse_ ("scarier") than regular HTTP, which is not true.

~~~
mindslight
Well, it's not really a continuum. 'There should be only one mode, secure' and
all that - asking users to make ad-hoc security assessments is generally a bad
idea. In an ideal world, plaintext HTTP wouldn't exist and everyone would have
a key delegated by their domain registrar.

No lock would suffice for unauthenticated https; those that find the
distinction meaningful can investigate the URL. But then you still risk
someone bookmarking [https://example.com](https://example.com) and suffering a
downgrade attack from not paying attention to color changes.

The best way forward is probably the creation of a new protocol designator
(httpz or something) that is SSL using the SSH key model. But there's no
impetus to do this as it's easy enough to pay the CA tax and be on your way
with unquestioned "full security".

------
Yaa101
Depends what you want, if you want trust that you can only grant yourself,
then go for self signed, especially internal projects.

If you want exposure of your certificates to common browsers and don't want to
raise warnings in them, go for cert authorities.

But remember Snowden, certificate authorities are less trustfull than you can
trust yourself.

~~~
ds9
This is the right answer and it's too bad it was way down the page (I
upvoted).

For your situation, mark_I_watson, probably get a cert from a CA, the cheap
"domain only" variety where you can verify your site to the CA simply by
putting a file in the web root directory.

I say this assuming the content is whatever you were already displaying to the
world without encryption - therefore low-security. The cert allows you to put
meaningful authentication on your site (otherwise passwords go in plaintext,
for example).

For a medium security level, sufficient for online money transactions, you
would have to get a higher-assurance type of cert - this requires more money,
sending business and personal ID documents to verify your business to the CA,
etc..

For really secret communications - getting into a degree of NSA-proofing -
among other things you have to avoid involving a CA, and preferably make
browser certificates for trusted clients, to spare them the warnings that
browsers throw up on non-CA server certificates. This is unsuitable for
(legal) commerce (commercial payment processors would reject your business),
and still vulnerable to metadata collection (unless you put it on TOR or
equivalent), and still vulnerable to state coercion of private keys or forced
code-trojaning.

Note that the third solution requires that your clients have a means of
verifying that the site is yours rather than an imposter - you avoid a CA
having the power to enable some other site to impersonate yours, but trusted
users must have a basis for trust by a "side channel" such as knowing you
personally, you being their employer, or reputation of your digital signature
over time.

~~~
dvanduzer
Could you elaborate on what you find meaningful about the authentication a CA
provides?

Another neat trick is creating your own CA, and putting your root into the
local trust stores of client nodes that you care about. (Be sure to
permanently airgap your root key, and create intermediate signers.)

~~~
ds9
I meant that sending logon + password is somewhat pointless if it's plaintext
over the internet, while if you have some encryption going on, someone
intercepting the data in transit would have a harder time using it to trick
the client or the server. In that sense authentication is more meaningful with
a certificate -- even though using a CA still allows interception by a
government actor. It narrows the range of those who can "break" the attempted
security.

~~~
dvanduzer
Well, a self-signed certificate still offers that encryption.

None of my arguments about X.509 / CAs are about government actors in
particular, though. There are enough root CAs trusted by the major browser
vendors that breaches can (and have) happened with minimal resource
expenditure.

------
Spittie
[https://www.startssl.com/](https://www.startssl.com/) gives out free SSL
certificates. Just don't expect much on their part, given it's free. For
example, they refused to reissue certificates for free after Heartbleed. Also
you can't use them on commercial sites.

otherwise [https://www.gogetssl.com/](https://www.gogetssl.com/) is probably
as cheap as it gets.

~~~
digitalchaos
If you read startssl'a justification on the free cert, you'll see that they
charge in relation to the time they need to spend. A low level 1 year cert
involves no human time. They don't have fully automated systems for
revokes/reissues, so it's pretty lame for people to complain about them
charging for it.

~~~
Silhouette
That's perfectly fair and reasonable from a commercial perspective.

From a security perspective, however, I think you need to meet some minimum
standards to remain credible as a CA, and I think at least being willing to
revoke certificates that may have been compromised for free and very quickly
is one of those standards.

I find it difficult to support retaining StartSSL certificates as trusted-by-
default in browsers given their response to Heartbleed and the consequent
relatively high probability that any certificate ultimately depending on them
has been compromised.

~~~
digitalchaos
That's understandable and probably a good reason for startssl to build an
automated revoke tool, for the sake of keeping their name healthy. However, I
would be way more concerned about a company unwilling to pay a trivial amount
of money to revoke a cert that was compromises due to their own choice in how
they used it. The best CA in the world won't fix bad security incident
handling of another company.

Sure, most of the complaining was due to the entitlement, but I'd be
interested in a list of all the companies that complained about this and/or
failed to pay for a revoke.

~~~
MichaelGG
I'm surprised it's not a requirement of being a CA. Further speaks to the
apparently weak standards the browsers have.

------
blumentopf
If your zones are signed with DNSSEC, just add a TLSA record for the self-
signed certificates to the zones. Clients with DANE [1] support will then
recognize that the self-signed certificates are valid.

Of course, very few clients support DANE as of yet. Nevertheless, that is the
most modern solution and you'll spur adoption of DNSSEC and DANE if you offer
it to clients.

[1] [https://tools.ietf.org/html/rfc6698](https://tools.ietf.org/html/rfc6698)

~~~
Osmium
Off-topic, but speaking of spurring adoption of DNSSEC: does anyone know of
any good (dumbed-down) guides on setting up DNSSEC on personal domains / using
dnssec-keygen? I keep seeing it mentioned in HN threads as a Good Thing, and I
know my registrar supports it, but they have a big warning:

"It is strongly recommended that you do not enable this option unless you have
a good understanding of what it is and does: you could easily make your domain
name inoperative."

which doesn't exactly inspire confidence, especially since most small website
owners (such as myself) really don't have a good understanding of it!

~~~
chimeracoder
> I keep seeing it mentioned in HN threads as a Good Thing,

Opinions on DNSSEC are... mixed, to say the least:
[https://news.ycombinator.com/item?id=5571937](https://news.ycombinator.com/item?id=5571937)

As a small website owner, are you using TLS? That's the biggest single thing
you should be doing - don't worry about DNSSEC.

This depends on what you mean by "small", but IMHO, you don't need DNSSEC.
Depending on how small/important your website is, you probably don't even need
to bother with DNSCurve either, though you might like to for the fun of it.

~~~
Osmium
Thanks for the link; that's actually very informative. My interest in DNSSEC
came from reading that it provided a mechanism to securely transmit SSH host
key fingerprints, though I'm not sure if there's a better way of doing that.

> As a small website owner, are you using TLS?

Yes, but I don't require it. Just a free certificate from StartSSL.

------
anu_gupta
One thing that always confuses me is the plethora of options for buying SSL
certificates.

I understand the difference between a single domain and wildcard SSL. But, as
an example, what's the difference between Positive SSL and Essential SSL (2
types of SSL certs sold by Namecheap) - Essential being about 3x the price.

~~~
logn
I think at some point I contacted support about that. It generally comes down
to one of a few issues:

compatibility (mobile, different browsers, etc)

steps taken to verify (via phone, email, fax, proof of business registration,
etc)

insurance (they'll offer various amounts of payment in liability insurance)

------
cjbprime
It's terrible, because Man-In-The-Middle attacks are trivial and automatable.

namecheap.com sells PositiveSSL certs for $9/year -- that's pretty cheap and
easy.

~~~
mark_l_watson
Thanks. I needed some encouragement. I will buy two PositiveSSL certificates
today.

~~~
nmb
You might be able to use StartSSL's free one:
[https://www.startssl.com/](https://www.startssl.com/)

~~~
kamaln7
Just keep in mind that Class 1 (free) certificates are for non-commercial
sites only.

~~~
pyvek
Also, StartSSL's certs don't work on android (you get cert not trusted error)
for some reason.

~~~
dvanduzer
I haven't checked any recent Android trust stores, but this _might_ be due to
a lack of an intermediate certificate.

The vast majority of modern browsers know how to find intermediate
certificates online. Android's browser doesn't, for whatever reason. You have
to bundle it on your web server.

~~~
pyvek
That was the problem. Works well on my android now. Thanks!

------
revelation
TLS means Transport Layer Security, and people would do good to remember it
was not invented to be used in the HTTPs browser webserver configuration
exclusively. For that particular application though, it doesn't make sense to
use a self-signed certificate as you can't control the client side and modern
browsers will raise hell.

There are however many applications where a self-signed certificate (chain) is
perfectly fine and even preferred. Think of mobile apps where you have control
over how certificate validation is done on the client-side.

------
lsh123
Self-signed cert is probably a bad idea in pretty much all cases. But
implementing your own CA is a different story. And the answer to your question
for your own CA is the usual - "it depends" :)

For an external web application/web service/API/... it is pretty bad. Users
will run into certificate errors with their browsers or the code. Some will be
smart enough but many will be scared away. Not good for your growth plans :)

For an enterprise web apps it is a completely different game. Pretty much you
MUST setup your own CA (for example, it would allow you to spy on your
employees - if you are paranoid about leaking secrets to competitors or
press). The usability issue is not a problem since the laptop/desktop will be
configured by the IT team anyway and they can setup the trusted certs along
the way.

Lastly, for your internal mid-tier services (you are following SOA, right?)
having your own CA would allow you to create as many certs as needed fast and
"for free". Thus, you can easily implement cert based authentication and
separate roles for different mid-tier/backend services. By implementing the
usual security measures to protect private keys (including root CA keys), you
actually get a much better security than using one "real" cert for everything.
Again, configuration should not be a big deal since you are controlling
internal services and network anyway.

------
PhantomGremlin
Anyone interested in how certificates work in "the real world" should install
Certificate Patrol (I think it's only for Firefox).

You will quickly learn that certificates are 99% noise. Here are some
observations:

1) ad sites present certificates, constantly changing. I don't care about
them, but at the moment there is no way to tell Certificate Patrol to
completely ignore certificates from a domain. The vast majority of
certificates presented to a browser are from ad sites.

2) major websites use a plethora of constantly changing certificates. Quite
often even the root signing certificate changes. Certificates change in days
or weeks, not months or years as might be expected by simply looking at
validity dates.

3) Some commenter [1] linked to an mitm paper written by Facebook people. It's
enlightening. The paper also makes the point that while a certificate
identifies a website, it doesn't identify a browser. So, even ignoring all the
possible firewall MITM and malware, how can a website be sure that a _user_ is
who he says he is? Only half the problem is solved unless the user presents a
certificate to the website. Most aren't set up for that.

[1]
[https://news.ycombinator.com/item?id=7826420](https://news.ycombinator.com/item?id=7826420)

------
MyDogHasFleas
I don't know why you're bothering with SSL at all. Your use case is that your
site is informational, it's intended to be open to anyone, there is no
personal/customer information on it, and there's no authentication (everyone
is anonymous).

All adding HTTPS support will do is make it marginally harder for someone to
spoof your site.

And why is NSA surveillance a concern? Your site is wide open for anyone to
see, with or without HTTPS.

~~~
simon_vetter
By sending data in plain text, your users are revealing their intent to
retrieve the content hosted on the site, even though that content is public.

That in itself may be considered a breach of privacy, as it exposes your users
to passive capture and profiling.

Also, accessing the content you are hosting might be considered legal in some
countries but illegal in others, regardless of if it is public or not.

~~~
MyDogHasFleas
Good points, but I would argue that HTTPS provides little protection against
this kind of access tracking.

Even if the site is HTTPS protected, a surveillance actor on the net would
still be able to read the entire site, maybe to determine if the site has
content worthy of tracking those who access it.

And, surveillance would still reveal that your IP address is accessing the
site, and thus triggering something.

What HTTPS would protect is the specific URL path you are going after on the
site, because that's in the HTTP GET which is part of the encrypted data
traffic.

I guess you could say that maybe the site has some pages that are more
sensitive than others, and revealing the exact URL paths you are accessing
might set off a surveillance trigger that would otherwise not be noticed. But,
the site in question is probably not like that.

------
binarymax
As others have said - don't use a self-signed cert. When you do settle on a CA
and config your SSL - this tool from SSL labs will really help. I used it
today to identify and resolve a chaining issue. It makes sure you've done
everything correctly.

[https://www.ssllabs.com/ssltest/analyze.html](https://www.ssllabs.com/ssltest/analyze.html)

------
gmuslera
Certificates not just encrypt communication, they also tell that the site is
really the one you think.

In that sense self-signed certificates are mainly useful for small amount of
people when you have another way to validate that the certificate is valid
(i.e. installing it in person in the intended client devices). Else anyone
could just create another certificate with the same human readable info.

There are some free or cheap enough certificates around that are already
suggested, and other ways to validate certificates that may be useful even for
self-signed ones, like [http://convergence.io/](http://convergence.io/)

------
dombili
I'm not a tech savvy person (at least around here) but I used Gandi to
purchase my certificate. I paid 12 bucks and it was extremely easy to
implement it. To give you an idea, I didn't even know how to enable access to
my site without entering "www." in front of my URL. But getting the
certificate and implementing it was so easy that I was actually surprised once
my SSL was active. I was expecting to run into a couple of problems as I
usually do when I deal with these sort of thing.

I'm using SSL for my personal website and it's not a commercial website.

~~~
tombrossman
I've got a couple at Gandi too, and I was pleased at how easy it was to set
up. I used the free first year (included with a domain name purchase) but then
went looking for the cheapest I could find.
[https://cheapsslsecurity.com/](https://cheapsslsecurity.com/) sold me a
simple domain validated cert for $19.96/5 years. That's the lowest I've seen
but it looks like they raised their prices slightly since then.

~~~
dombili
Honestly, I don't mind that Gandi isn't offering the cheapest option out
there. My domain and my host are from Gandi, so it was a no brainer for me to
get my certificate from Gandi. I didn't even check the alternatives. If it was
a hefty price, say, like $50/yr instead of $12, I'd have probably looked for
other alternatives but I'm happy with them so far and I like to reward
companies that serves me well as a customer.

------
dk8996
We just went through this process at my startup. The gist of it is that if you
self sign your certificate the user will get a warning say "do you trust this
site? yes or no" \-- this will lead to alot of people leaving. The best option
is to get a cheap signed SSL certificate, godaddy has them for like 70$ a
year. You can probably shop around a get them for cheaper. Moreover, if your
using AWS, consider letting ELB (elastic load balancer) handle the HTTPS.

------
benatkin
You should quit using them if anyone other than you ever needs to open the
page in a browser. The warnings will never be good enough for partial clicking
through of them. If a user (even a technical one) gets talked into clicking
through an SSL error, it is likely that they have been talked into a bad
habit.

------
herf
It used to be pretty easy to install a self-signed certificate from the
browser. Now it seems quite a bit harder--e.g., in Chrome you seem to have to
export it to a file, I think? And in IE people say they can't even _inspect_ a
bad certificate, because the UI hides it entirely.

------
jeffmould
If money is short at the time you can also get a 90-day free SSL from Comodo.
Good for testing and getting SSL setup or if you are tight on funds at the
time it can get you started until you have the cash on hand to purchase the
certificate.

------
mark_l_watson
I posted this Ask HN earlier today. Thanks for the useful comments.

I have decided to not use a self signed cert.

Another question: any comments on CloudFlare's auto SSL support on paid plans?
$20/month does not seem too much for CDN and SSL support.

~~~
mark_l_watson
EDIT: I did go with CloudFlare: works great, and my site is loading faster.
Seems worth $20/month.

------
pbreit
They are pretty bad from a user perspective. Some of the browser UIs make it
very scary looking to continue, if you can even figure out how.

If, as you say, just an information site, I would get rid of them immediately.

------
ChrisAntaki
It's good, because you have control over the certificate creation, and never
have to share your private key.

The one catch is, as you noticed, the key has to be distributed. Depending on
your goals, and your audience, this might be impractical, or within the realm
of reason.

Here's a link that goes into more detail.

[https://blogs.oracle.com/java-platform-
group/entry/self_sign...](https://blogs.oracle.com/java-platform-
group/entry/self_signed_certificates_for_a)

~~~
ckuehl
> It's good, because you have control over the certificate creation, and never
> have to share your private key.

You will never have to share your private key when getting a certificate from
a proper CA, either.

~~~
dvanduzer
This is true, but you wouldn't believe the system-as-practiced by most large
IT departments.

edit: small IT departments, too. nobody really pays attention as long as the
lock icon is green.

~~~
yaur
Can't speak to the state of this on Linux, but on Windows/IIS if you "just
follow the wizard" and send the generated file to your CA it will not include
the key.

~~~
dvanduzer
My remark wasn't about the software tools, it was about the human processes
around them. There are major knowledge gaps in every organization I've ever
interacted with (hundreds) that use certificates.

For example: How do you get the private key to a _second_ IIS server, if you
are doing poor man's DNS load balancing with the same hostname?

------
jbrooksuk
Is it worth adding HTTPS when you're running an internal app?

------
markgamache1
YOU ARE DESTROYING THE INTERNET

Training users, who have no way to properly asses this risk, to click OK to
the SSL error, is like Jim Jones's practice runs drinking the Koolaide.

Firefox had it right when the briefly made it impossible to OK the use of
misconfigured SSL.

Most IT people don't understand the risk of self-signed certs. We can't expect
users to make good choices here.

~~~
romanovcode
It's still more secure than plain-text http tho.

~~~
MichaelGG
Since there's no way to distinguish MITM and an unverified certificate, it can
make people think they are secure when they are not. That's not "more secure".

