Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Encrypt and Nginx – State of the art secure web deployment

letsecure.me

Post reply on HN
Print view View original

31–40 of 85 posts

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#31

Post by icebraining »

schoen wrote: post #25

It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.

Unfortunately, it seems there's no secure way to fetch the key. The nginx team recommends one checks the "web-of-trust" to check if the key is signed by others.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#32

Post by icebraining »

tbrock wrote: post #29

Lets encrypt fixes the encryption problem sure but does anyone else feel that all we really needed was really great documentation on what to do instead of an intrusive set of scripts?

No, because you need the automation to make the short expiration times bearable, and having those short expiration times is more secure.

Besides, the official script is just one part of the project; the others are (1) free certs and (2) a standard protocol, which you can use with other tools.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#33

Post by rajivm »

icebraining wrote: post #31
schoen wrote: post #25

It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.

Unfortunately, it seems there's no secure way to fetch the key. The nginx team recommends one checks the "web-of-trust" to check if the key is signed by others.

At the least though it could be https.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#34

Post by ivansavz »

schoen wrote: post #30
ivansavz wrote: post #24

The --webroot option doesn't work for my setup, so I need to shutdown nginx for 2-3 seconds and use the --standalone option. I set this as a CRON job that will run every two months. It's not elegant, but it's done. Here's the modified script using certonly and the --force-renew flag. #!/bin/bash # Force-renew the "Let's Encrypt" certificates for a given domain # Run this as root as a BI-MONTHLY cron job export DOMAIN…

Do you ever get problems with the socket still being in use after nginx is shut down?

Not on the N=1 times I've run the script, but will look out for this in the future.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#35

Post by schoen »

rajivm wrote: post #33
icebraining wrote: post #31

Earlier quoted context omitted.

Unfortunately, it seems there's no secure way to fetch the key. The nginx team recommends one checks the "web-of-trust" to check if the key is signed by others.

At the least though it could be https.

I also suggested that in the meantime the author of the article can provide a SHA256 checksum, so you can see if you get a different key than he does.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#36

Post by IgorPartola »

I have been happy with https://github.com/lukas2511/letsencrypt.sh. I am trying to get it packaged for Debian/Ubuntu and either get it into Debian-proper or at least host the repo myself to make it easier to use for the common case. Since nginx reloads the cert on a SIGHUP it makes it really easy to have zero downtime renews.

As for getting notified if something goes wrong I use the following in my crontab:

    10 5 * * *  root    test -e /usr/local/bin/letsencrypt.sh && /usr/local/bin/letsencrypt.sh -c > /dev/null
letsencrypt.sh outputs errors to stderr, so any errors will be sent to the root account. To get that working, do:

    apt-get install postfix
    echo 'postmaster:     root' > /etc/aliases
    echo 'root:           igor@example.com' >> /etc/aliases
    newaliases
Problem solved.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#37

Post by llambiel »

schoen wrote: post #25

It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.

I agree with your concern. As a temporary "workaround" I've updated the article with a SHA256 checksum of the key. I'll chase the Nginx team for serving this key over https

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#38

Post by schoen »

llambiel wrote: post #37
schoen wrote: post #25

It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.

I agree with your concern. As a temporary "workaround" I've updated the article with a SHA256 checksum of the key. I'll chase the Nginx team for serving this key over https

Thanks for the update!

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#39

Post by rlpb »

icebraining wrote: post #31
schoen wrote: post #25

It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.

Unfortunately, it seems there's no secure way to fetch the key. The nginx team recommends one checks the "web-of-trust" to check if the key is signed by others.

Stick it on a keyserver, and then ask gpg to fetch it from that keyserver with the full fingerprint. Assuming that your instructions that include the fingerprint are secure (which they have to be, else the instructions could root your box anyway), then that should be reasonable.

This does assume that gpg verifies that the key retrieved matches the ID requested, which I assume it does. Otherwise that'd be quite a serious bug.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#40

Post by icebraining »

rlpb wrote: post #39
icebraining wrote: post #31

Earlier quoted context omitted.

Unfortunately, it seems there's no secure way to fetch the key. The nginx team recommends one checks the "web-of-trust" to check if the key is signed by others.

Stick it on a keyserver, and then ask gpg to fetch it from that keyserver with the full fingerprint. Assuming that your instructions that include the fingerprint are secure (which they have to be, else the instructions could root your box anyway), then that should be reasonable. This does assume that gpg verifies that the key retrieved matches the ID requested, which I assume it does. Otherwise that'd be quite a seri…

The question is how to ensure you're getting the right fingerprint. If you have that, you can just as easily fetch the key using HTTP and verify it.
Post reply on HN