
Get HTTPS for free - somecoder
https://gethttpsforfree.com/
======
diafygi
This is my project, happy to answer questions or receive feedback. The goal
was to let people experiment with getting a Let's Encrypt cert before the had
to install anything on their server. The static/unhosted property is to
strengthen trust that nothing shady is going on here.

~~~
pytrin
Does this support wildcard subdomains? If not, would you be willing to add
such support?

~~~
toupeira
This uses LetsEncrypt which doesn't support wildcard certificates yet:

> Will Let’s Encrypt issue wildcard certificates?

> We currently have no plans to do so, but it is a possibility in the future.
> Hopefully wildcards aren’t necessary for the vast majority of our potential
> subscribers because it should be easy to get and manage certificates for all
> subdomains.

From [https://community.letsencrypt.org/t/frequently-asked-
questio...](https://community.letsencrypt.org/t/frequently-asked-questions-
faq/26)

~~~
pytrin
Unfortunately, that doesn't work with dynamic subdomains (i.e, domains
assigned and edited by users). Hopefully they'll change their minds in the
future - until then, I'll be paying for a commercial certificate

~~~
dyladan
You could always script the letsencrypt API and generate a new certificate on
each subdomain generation.

~~~
pfg
That's correct, however there are rather aggressive rate limits in place right
now that would make this hard for your typical SaaS-on-a-subdomain deployment
if you have more than ~5 new signups per week. Plus, if SAN support is a
concern, wildcards are preferable too.

~~~
jrochkind1
The rate limits[1] I see documented are 500 registrations per 3 hours. That's
a lot more than ~5 new signups per week. More like ~16800 new signups per
week, no?

[1] [https://community.letsencrypt.org/t/rate-limits-for-lets-
enc...](https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769)

~~~
pfg
Certificates/Domain is the one that would affect this use-case the most. It's
set to 5 certificates per domain per week. More specifically, it's
certificates per TLD+1, so one certificate for customer1.example.com and one
for customer2.example.com would put your rate limit for example.com at 2, thus
limiting you to 5 signups per week unless you spread your SaaS over multiple
TLD+1's.

~~~
derefr
How do they define a TLD? What's, for example, .co.uk to them?

~~~
pfg
They use the Public Suffix List[1].

[1]: [https://publicsuffix.org/](https://publicsuffix.org/)

~~~
jrochkind1
Hmm, are you sure they do? Including the "PRIVATE" section? Any docs from them
saying this, and clarifying whether this includes the PRIVATE section?

Because if so, that would seem to make the certs-per-domain limits not so much
of a problem. If you own example.com, and have customers using sub-domains at
a.example.com, b.example.com, etc -- that would seem to make example.com
suitable for inclusion on the "PRIVATE" section of the list.

No?

"owners of privately-registered domains who themselves issue subdomains to
mutually-untrusting parties may wish to be added to the PRIVATE section of the
list... Requests for changes to the PRIVATE section must come from the domain
owner."

[https://publicsuffix.org/submit/](https://publicsuffix.org/submit/)

And indeed there are a few dozen random .com, .net, etc domains in the PRIVATE
section. For instance `github.io` is listed there.

If that's the way for SaaS providers to get free certs from letsencrypt for
their customers at customername.provider.com, I'd expect to see the listings
in the PRIVATE section skyrocket.

~~~
pfg
Yes, private suffixes are included. It has already caused a spike in new PSL
submissions[1].

You're right about this being rather easy to bypass, but the main goal is
probably not to mitigate against abuse but rather prevent buggy automation
scripts stuck in some kind of infinite loop from DDoSing them.

[1]: [https://community.letsencrypt.org/t/dyndns-no-ip-managed-
dns...](https://community.letsencrypt.org/t/dyndns-no-ip-managed-dns-
support/883/16?u=pfg)

------
oliv__
_Slightly off topic_ :

I know everyone here is all about naked websites but I couldn't help but add
these three lines of CSS to the body:

    
    
      max-width: 630px;
      margin: 0 auto;
      padding: 0 15px;
    

Makes the whole thing much more pleasant to read! (And even looks good on
mobile)

Here's a screenshot: [http://imgur.com/UFHJp8a](http://imgur.com/UFHJp8a)

~~~
sccxy
[http://bettermotherfuckingwebsite.com](http://bettermotherfuckingwebsite.com)

~~~
fizixer
Grey text is one of the silliest trend I have seen.

If you've changed the background from white to light-grey, that's enough. Stop
changing text from black to dark-grey (especially the non-bold text)!

~~~
jakub_g
10x this. See [http://contrastrebellion.com/](http://contrastrebellion.com/)

When this is additionally compounded with a non-standard super thin font, the
result is text almost invisible, even when zoomed, at least on non-retina non-
macs.

I also noticed some (very few, but not that rare) websites use a font that
looks completely rubbish on my Windows machines (certain serifs not being
displayed, making it impossible to decipher letters). I thought it was
impossible that every Windows user had this, they would have learnt. Turned
out my ClearType settings hugely affected the rendering of mentioned font
(ClearType is antialiasing method on Windows, when you enable it, it goes
through manual calibration process, hence every Windows machine may have
radically different config)

Don't go wild with colors and fonts for main content of the page. The more
standard ones you use, the better chance it will render well for every user.
Not everyone has same device with same config as yours.

~~~
jsmthrowaway
When you're aware that high contrast can exacerbate and trigger scoptic
sensitivity reactions in those with dyslexia, that page takes on a different
tone.

~~~
cuckcuckspruce
Okay, so should I have to provide a screen reader download with my website as
well? If you have a condition that between 5 - 17% of the world has[1] then
you should be responsible for setting up your own environment (possibly with
the help of your OS) the way it works for you.

[1]
[https://en.wikipedia.org/wiki/Dyslexia#Epidemiology](https://en.wikipedia.org/wiki/Dyslexia#Epidemiology)

~~~
jsmthrowaway
You want a huge portion of the world, most of whom not knowing how, to
override your stylesheet because you can't be bothered to take five seconds to
ease up on contrast (or even consider it)? Please tell me you're joking.

This is why the ADA happened.

~~~
cuckcuckspruce
>You want a huge portion of the world, most of whom not knowing how, to
override your stylesheet because you can't be bothered to take five seconds to
ease up on contrast (or even consider it)?

No, but given the way that the web and browsers are designed, along with the
way that my site is designed the option is there for people that want to take
it. Again, should I have to provide a link to a spoken version of my website
in case somebody who is blind doesn't have a screen reader installed?

ADA is about making things accessible. So long as somebody can, with
reasonable accommodation, access my website (for example, my design being
simple and trivially overridable with user styles) then I'm accessible. If
someone with dyslexia cannot handle the contrast levels of my site because a
small minority of dyslexic users have their dyslexia triggered by that amount
of contract then that is precisely what user style sheets are for, and I don't
think it's unreasonable to ask somebody who is a minority of a minority to use
the tools that are provided implicitly for them to configure things in a way
that is easier for them.

------
Smudge
> This website is static, so it can be saved and loaded locally. Just right-
> click and "Save Page As.."!

This strikes me as particularly neat. I wish more SPA's were able to work like
this.

~~~
dham
It would be somewhat hard. You couldn't do things like CSRF tokens or any kind
of data that comes from the server and rendered on the page. Also the assets
couldn't be named with hashes to be cached indefinitely.

But the concept is interesting.

~~~
mintplant
> Also the assets couldn't be named with hashes to be cached indefinitely.

I don't see why not.

------
robmclarty
For those that are interested, I posted an article[1] a little while ago on
how to automate the renewal process for Letsencrypt using Daniel's acme-
tiny[2] script. It's a lot nicer to let cron handle it than doing it manually
;)

[1] [http://robmclarty.com/blog/how-to-secure-your-web-app-
using-...](http://robmclarty.com/blog/how-to-secure-your-web-app-using-https-
with-letsencrypt)

[2] [https://github.com/diafygi/acme-tiny](https://github.com/diafygi/acme-
tiny)

------
godzillabrennus
This is definitely a step in the right direction. It's bugged me that vendors
are leveraging a commercial and proprietary system to secure sites. If we are
going to move forward with this as the baseline of security for public facing
sites then it's good to see a free and transparent solution pop up to help
lower costs for students and the developing world.

------
c0l0
Very nice, I quite like it!

I recently hacked together a completely web-based, client-side CSR generator
for PKCS#10; you can take a look at it at
[https://johannes.truschnigg.info/csr/](https://johannes.truschnigg.info/csr/)
With something like that fused into your project, users wouldn't even have to
execute `openssl` to generate their key material and CSR, they'd just need a
modern browser with support for the W3 Web Cryptography API.

~~~
nailer
We also use webcrypto on [https://certsimple.com](https://certsimple.com)

If people prefer, we also dynamically generate a full OpenSSL or powershell
command,so they can make keypairs on their own server with a single paste - no
terminal Q and A.

We're awesome, but there's nothing stopping you from using the tools wherever
you want. :^)

------
rogerbinns
What is the HTTPS/security solution for devices on a home/office LAN? They
aren't externally accessible, don't have a globally unique name, but do have
access to valuable content (think your router, baby camera, lighting
controller, NAS, media device).

Having to teach users that you always see the padlock when accessing your
valuable information over the Internet, but do not see it when accessing your
even more valuable information on the LAN doesn't seem good.

~~~
pfg
Office setups: Deploy an internal root CA (possibly with appropriate name
constraints, to limit the damage to internal domains if your CA key is
compromised). Active Directory makes it relatively easy to do this.

Tooling will hopefully get better now that browsers are pretty much set on
going HTTPS-only.

Some consumer devices could probably implement something similar to what Plex
did to deploy TLS [1].

I do agree that the industry isn't where it should be yet, but hopefully
everyone's feeling the pressure now. :)

[1]: [https://blog.filippo.io/how-plex-is-doing-https-for-all-
its-...](https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/)

~~~
rogerbinns
Your office setup only works for the larger ones. And then for Windows
machines that are actively managed. It doesn't for example address a BYOD
iPhone.

The Plex solution looks good. I wonder if lets encrypt could provide a similar
solution that works for everyone, rather than products having to reimplement
what Plex already did.

------
nulltype
The Let's Encrypt certificates seem to expire after 90 days. I wrote up some
example code in Go so you can automate the process of issuing these certs
here: [http://goroutines.com/ssl](http://goroutines.com/ssl)

It does not require CSRs, but uses your DNS provider to complete the
challenge. You do not need to run anything on your production servers.

~~~
imron
Yes, the intent is to have short expiry times to encourage people to
completely automate the process.

~~~
tomjen3
Unfortunately that makes it more complicated too, which means fewer people
will use it (a classic example of a trivial inconvinience
[http://lesswrong.com/lw/f1/beware_trivial_inconveniences/](http://lesswrong.com/lw/f1/beware_trivial_inconveniences/)).

~~~
nulltype
Honestly renewing certs is a huge pain and should be automated even in the 1
year case. I usually have forgotten after a year how I obtained and installed
the cert last time.

The Lets Encrypt flow with DNS is way less complicated than obtaining a cert
through many commercial services, so it probably works out about even.

------
satbyy
I had been using free Startcom SSL certs, but their UI and overall experience
was not as great as this simple website. I just generated mine in about 10
minutes. The last I remember was that StartSSL required something to be stored
on my local browser, but I reinstalled my browser, so lost some certificate,
etc. If was free, but painful. I know I should automate every 3 months, but
even when I miss it, I know I can use this website and manually generate a
cert in 10 min.

Thanks to OP, diafygi and Lets Encrypt !

~~~
rogerbinns
Startcom insist that you have your own personal certificate first, before they
will issue the website certificate. They could have allowed just a username
and password, but I guess certificate authorities believe there is no such
thing as too many certificates, and don't realise just how inconvenient they
are for most people.

(It was their personal certificate they issued to you that had to be in the
browser.)

~~~
simoncion
> Startcom insist that you have your own personal certificate first ... [t]hey
> could have allowed just a username and password...

I assume that this was for TLS client authentication. Username+password
_sucks_ as a method of authentication. The _only_ thing it has going for it is
that you can -theoretically- remember your password and key it in on a machine
you've never used before. [0]

Client certs are effectively unguessable and typically stored in the most
secure place that the OS can provide. What's more, there's -IIRC- absolutely
_no_ reason for the remote side to remember anything about the certificate
that they issued you after they generate it, so there's no risk of a server-
side DB breach revealing any significant information about a client's
credentials.

Frankly, I wish more sites would eschew username/password authentication for
username/cert (or at least offer the _option_ of username/cert). Then the UI
for certificate operations would _certainly_ get easier to use. :)

[0] Though, in today's environment, it seems... highly unlikely that any non-
mutant will be able to remember all of the passwords for all of the sites that
they use.

~~~
rogerbinns
Given a clean slate you could possibly make some sort of case for client
certificates. But right now username + password is the standard, and people
can continue to use whatever solution they deem fit for that.

Client certs might in theory be stored in "secure places", but that is not the
case in practise. Have anyone get a client cert, and then make a backup or
copy to another device. I'll guarantee it is trivially accessible - eg sending
it in clear email to yourself to get from one machine to another.

It doesn't matter how secure something is, if a standard user would find it
highly inconvenient, and it doesn't recognise the modern world of the same
user having multiple devices in multiple locations.

~~~
simoncion
> Given a clean slate you could possibly make some sort of case for client
> certificates. ... It doesn't matter how secure something is, if a standard
> user would find it highly inconvenient...

You obviously missed the point of my comment. I'll highlight the part that
most clearly captures the essence of my point:

"Frankly, I wish more sites would eschew username/password authentication for
username/cert (or at least offer the option of username/cert). Then the UI for
certificate operations would _certainly_ get easier to use."

> ...and it doesn't recognise the modern world of the same user having
> multiple devices in multiple locations.

Easy fix: issue one cert per device. Does the UI for this suck right now? Yes.
Does it _have_ to suck? Fuck no.

> Client certs might in theory be stored in "secure places", but that is not
> the case in practise.

It absolutely _is_ the case in practice.

Imagine a hypothetical magical computer that stores all username/password
pairs in a magical HSM that never lets the username/password outside of the
HSM, ever. The credentials in this system _are_ stored in the most secure
place that the computer can provide. The fact that the _user_ of that system
may have _also_ written those credentials down on a sticky note under his
keyboard or saved in a plaintext message in his webmail mailbox does _not_
change that fact.

Does that make sense?

~~~
rogerbinns
I got the point about client certs being more convenient at the point of
authentication. My point is that they are _considerably_ less convenient at
all other times. How do you get a cert from a Windows machine running IE into
an iPhone running Safari? Or vice versa. What about when one of them is off?
How do you get a cert onto a device you will use in the future that is in
another location under someone else's control.

I don't understand how you issue one cert per device. There would be a
bootstrap problem, presumably solved by entering a username and password. Or
some mythical software/system that is able to securely distribute and update
your certs across your systems.

Chrome stored my client cert from Startcom in a file in my home directory. Any
app running as my user id has access to that file. Since this is a personal
workstation, pretty much all the software (some system daemons excluded) runs
as me. I don't consider this a secure place in practise, hence the comment. I
do agree they could be done differently, but they aren't. Heck I've yet to
encounter any browser or similar that uses the TPM in my laptop for security
purposes.

Client certs seem very similar to ssh keys in usage and needs (secret blobs
that need to be backed up and distributed). I know several above average
developers who manage theirs well. But then I come across many who don't
because it requires too much mental effort. It gets reflected in using
passwords for git operations at github. A trivial number of the people who get
them right, also don't bother with PGP for email because that is even more
painful.

For client certs to have any hope of wide usage, the non authentication issues
need to be solved, and there is nothing even close.

~~~
simoncion
> Chrome stored my client cert from Startcom in a file in my home directory.

I gather that you don't have a smart card attached to your system? This [0]
indicates that Chrome uses Mozilla's NSS to store certificates. The
documentation for NSS indicates that it's happy to work with certs stored on
(or to store certs on) a smart card. :) Granted, the UI "sucks" for this, but
that's part of my point.

> I got the point about client certs being more convenient at the point of
> authentication.

 _That 's_ not what I was saying. Client certs are _unguessable_ , the
authenticating partner has no need to store _any_ significant information
about the cert, and certs typically rest in the most secure storage the OS can
provide. [1] Certs are _leaps and bounds safer_ than passwords.

Right now, certs are typically _harder_ to use than than passwords.

> For client certs to have any hope of wide usage, the non authentication
> issues need to be solved...

I'm not trying to be confrontational, but didn't you see that this was
_exactly_ what I was saying in my previous two comments?

No need to write four 'graphs that largely restate what I already said. :)

Thing is, if noone uses a thing, the UI for that thing will _never_ get
better. You frequently _have_ to offer the thing as an option so that people
will start using it before UI design teams will deign to make the UI for that
thing better.

> A trivial number of the people who get them right, also don't bother with
> PGP for email because that is even more painful.

This is kind of a tangent, but: I guess those people don't use email clients
that have adequate support for PGP. Enigmail makes key management, selection,
and use _trivial_.

[0]
[https://chromium.googlesource.com/chromium/src/+/master/docs...](https://chromium.googlesource.com/chromium/src/+/master/docs/linux_cert_management.md)

[1] User mishandling notwithstanding.

~~~
rogerbinns
> I'm not trying to be confrontational ...

I am having trouble understanding what you are saying. The wording and tense
seems to switch between what is really happening today, versus what could
happen today given sufficient effort and implementation. I believe that other
than small niches (eg startcom, some smartcard use in corporate and DOD),
client certs are essentially unused by the vast majority of users. And I
believe that even if everywhere accepted them, the logistical issues around
ensuring a user has their certs in the relevant places are far too hard to
overcome no matter how big the magic wand :-)

> I gather that you don't have a smart card attached to your system?

Nope. I could get the smart card reader when I buy Thinkpads, but don't. And I
use Linux, Windows, Mac, Android and iOS. Having a smartcard reader on one
machine wouldn't really help.

> Certs are leaps and bounds safer than passwords.

Only if the user is perfect. All it takes is them emailing it themselves,
putting in Dropbox, being careless with backups or any number of other
scenarios and it has the same "safety" as a password. (That is assuming your
magic wand doesn't appear and somehow put smart card readers in every device
overnight. :)

> Enigmail makes key management, selection, and use trivial.

Enigmail is indeed exactly what I use. Your statement above is true, but
doesn't address the big picture. _Every_ time I install a new system, I have
to do copious amounts of googling to figure out exactly where my certs are
installed, and then copy them over to the new machine, and get them imported.
I'm never sure if I have done it right, haven't left myself open to compromise
etc. A somewhat distant friend works in security, and once asked several
people to email him their public keys. Virtually every response was a
_private_ key.

We've had decades of certs for PGP, everyone using it wants to be secure, and
everyone wants it to be better and "user friendly". The effort has been a
dismal failure.

------
dasmoth
Thanks for making such a great little tool.

Are you still intending to add a renew page at some point?

~~~
diafygi
Maybe, swamped at my startup (we're hiring!). Pull requests welcome!

~~~
theviajerock
Where can I see the open positions???

~~~
overcast
[https://angel.co/utilityapi/jobs](https://angel.co/utilityapi/jobs)

------
ausjke
This is awesome, just replaced my self-signed ssl with it. Great Thanks!!

so the cert will expire in 90 days, how to deal with that? come to the same
site every 3 months and regenerate a new SSL cert? Why not at least valid for
a year?

~~~
desireco42
If you find out, I would like to know as well.

~~~
mappu
Let's Encrypt is designed to encourage setting up an automated renewal system.
If you follow the links, you won't have to renew within 90 days - or ever
again.

------
nitrix
What is the intermediate certificate hardcoded in the source?

~~~
diafygi
The Let's Encrypt cross signed intermediate.

------
arihant
I plead ignorance here. I'm sort of out of touch with recent developments,
with typically just buying a cert when I need it. So I have a question --
where will Let's Encrypt certificates not work? I see Mozilla and Chrome as
sponsors, so I'm guessing it's added as authority in at least those browsers?

This would be great, apart from apparent insurance regular certificates bring,
which I still don't know how to claim.

~~~
ceejayoz
> So I have a question -- where will Let's Encrypt certificates not work?

They're very well supported. Won't work in Windows XP and Android versions
lower than 2.3.6. [https://community.letsencrypt.org/t/which-browsers-and-
opera...](https://community.letsencrypt.org/t/which-browsers-and-operating-
systems-support-lets-encrypt/4394)

> This would be great, apart from apparent insurance regular certificates
> bring, which I still don't know how to claim.

To my knowledge, that insurance has _never_ been paid out, from any SSL
vendor. It's a marketing gimmick.

------
cornholio
Since it's free, could this be included into the installation or configuration
scripts of major packages that provide web services ? As long as I have the
DNS set up, it would be great if I can run "dpkg-reconfigure exim4-config" and
have working STARTTLS with real certificates.

------
src
Free is great. My only issue with LetsEncrypt is that the certificates are
only valid for 3 months. It's a hassle to keep updating the certs...

I just switched to AWS Cert Manager last month from StartSSL, which is free if
you're an AWS customer.

~~~
ymse
3 months expiry time was a deliberate choice to force users to automate the
process. Ideally you would have a central store with a letsencrypt client, and
all your actual web servers periodically fetch their certs from there.

~~~
src
That's great except the web server (except apache/nginx) needs to be restarted
to load new certs, which isn't ideal for production. Many cloud hosting
providers don't have an automated way to update certs, which makes it more
tedious.

~~~
pfg
Both apache and nginx support graceful reloads which will reload the
certificates without any downtime.

------
jetskindo
Let's encrypt looks so cool with its very few steps. But then you install and
you get all sorts of errors not me toned on the page. I spent a good 5 hours
debugging yesterday.

When it finally works I see that the certificate expires in 2 months.

~~~
schoen
If you'd be willing to describe the problems you encountered in issues on
[https://github.com/letsencrypt/letsencrypt/issues](https://github.com/letsencrypt/letsencrypt/issues)
(if they're clearly problems with the client software) or in a forum post at
[https://community.letsencrypt.org/](https://community.letsencrypt.org/) (if
you're not sure), you can help other people have a better experience in the
future.

Not everyone is having five hours' worth of problems -- many people are
getting it to work right immediately -- but there are clearly also people who
are running into difficulties which it would be great to figure out how to
address.

------
blandes
Or you could use Amazon Web Services for their certificate manager? They offer
wild card certificates for free?

~~~
danielhlockard
You double posted, but FYI you can't export certs from AWS cert manager

------
blandes
Or we could Amazon Web Services for their wildcard certificates?

------
LCDninja
This is fantastic! Thank you very much for creating this!

------
nickkenens
These are the things we need for the web.

------
AndyKelley
Sadly Let's Encrypt still doesn't work if your ISP blocks port 80 and 443.

~~~
jrochkind1
I don't get it. If your ISP blocks port 80 and 443 incoming, how would you
possibly deploy a website anyway? What do you need an ssl cert for if you
can't deploy a website anyway?

~~~
AndyKelley
I run a music server[1] on my home server so I can listen to music anywhere. I
serve it on a port other than 80 and 443 since my ISP blocks those ports.

If I access the web interface over HTTP, the admin password is sent in clear
text, which means someone on the network I connect to could get my password
and delete my music, or god forbid, secretly mistag some of it.

* [1]: [http://groovebasin.com/](http://groovebasin.com/)

~~~
ceejayoz
Since it's for personal use, you can fire up something like an EC2 server,
point the domain there for a few minutes, and provision a LE certificate. Copy
down the generated key/cert files and you're in good shape for three months.

~~~
AndyKelley
I understand this would work, but obviously this is not free, and it's
certainly not elegant or optimal.

~~~
ceejayoz
It's free - AWS free tier - and if it weren't it'd cost you less than
$0.10/year for the couple hours of AWS nano instances you'd need.

~~~
AndyKelley
It's not free. "The AWS Free Tier includes services with a free tier available
for 12 months following your AWS sign-up date"
[https://aws.amazon.com/free/](https://aws.amazon.com/free/)

~~~
ceejayoz
Way to skate past the second part. A t2.nano instance costs $0.0065/hour. You
need it for a few minutes every three months.

