curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add -
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.
I'm looking at you Jenkins![0]
[0] https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenki...
Also, anyone suggesting that this method of downloading and installing software is secure due to its use of HTTPS is incredibly reckless.
I have "alias webserver='python -m SimpleHTTPServer'" in my shell config, but I think I'll switch to Caddy.
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
apt-get install postfix
echo 'postmaster: root' > /etc/aliases
echo 'root: igor@example.com' >> /etc/aliases
newaliases
Could not they do something nicer with systemd and email?
In my mind, I'm seeing "state of the art" being more like a combo of Ur/Web for apps, robust implementation of OP2 web browser for client, lighttpd rewritten in Haskell, HTTPS component written in SPARK or Rust, all running on GenodeOS or CheriBSD in isolated partitions, C parts compiled with CompCert extended with Softbound + CETS, anti-fuse FPGA doing I/O offloading/mediation, and hardware done in Bluespec. That is state of the art with probably badass results. This submission is... more run of the mill. Immediately useful, though. :)
Here's my notes on setting up LE on IIS if anyone one is interested, it's done by using Powershell/ Package manager.
//1. Install (you will get some security prompts) Install-Module -Name ACMESharp
Import-Module ACMESharp
Initialize-ACMEVault
New-ACMERegistration -Contacts mailto:somebody@example.org -AcceptTos
//2. Request the challange, this is for a website currently running on IIS. 'WebSiteRef ' refers to the name of the site within IIS
New-ACMEIdentifier -Dns demo.velox.io -Alias demo Complete-ACMEChallenge demo -ChallengeType http-01 -Handler iis -HandlerParameters @{ WebSiteRef = 'Demo' }
Submit-ACMEChallenge demo -ChallengeType http-01
//3. Create & download the certificate
New-ACMECertificate demo -Generate -Alias demoCert
Submit-ACMECertificate demoCert
Update-ACMECertificate demoCert
Get-ACMECertificate demoCert -ExportPkcs12 "C:\Users\USER\desktop\demoCert.pfx"
You can now install this on your server.
Add a config.sh and setup nginx alias. Then just add domains to the domains.txt and have the script run via cron daily.
Finished
> sed -i 's|PasswordAuthentication yes|PasswordAuthentication no|g' /etc/ssh/sshd_config
> grep PasswordAuthentication /etc/ssh/sshd_config
# PasswordAuthentication yes
> sed -i 's|PasswordAuthentication yes|PasswordAuthentication no|g' /etc/ssh/sshd_config
> grep PasswordAuthentication /etc/ssh/sshd_config
# PasswordAuthentication noHere'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 DOMAINS="yourdomain.com,www.yourdomain.com"
export LOGFILE="/var/log/letsencrypt/renewal_yourdomain.log"
echo "Stopping nginx temporarily to renvew certificates for $DOMAINS ..."
service nginx stop
echo "Calling /opt/letsencrypt/letsencrypt-auto certonly --standalone --force-renew -d $DOMAINS"
if ! /opt/letsencrypt/letsencrypt-auto certonly --standalone --force-renew -d $DOMAINS > $LOGFILE 2>&1 ; then
echo "certonly call failed, restarting nginx"
service nginx start
echo "LOG info:"
cat $LOGFILE
# TODO: email administrator...
exit 1
fi
echo "certonly call succeeded, restarting nginx"
service nginx start
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.
It's made me think we should have a Swagger or API Blueprint of the spec on github that everyone can keep up to date. What do you think?
The former is documented in the ACME specification[1], currently being worked on by the IETF. There are many low-level ACME libraries for basically every language[2], and a pretty decent guide on writing your own client as well[3].
[1]: https://ietf-wg-acme.github.io/acme/
[2]: https://github.com/letsencrypt/letsencrypt/wiki/Links#librar...
/opt/letsencrypt/letsencrypt-auto certonly --rsa-key-size 4096 --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path=$DIR -d $DOMAINS
# in your nginx.conf
ssl_ecdh_curve secp384r1;
I also recommand https://sslcatch.com which sends you a warning email if your certificate is about to expire. I have a crontab to renew it but this can be also helpful just in case.
Wrote about the process here: https://clay.fail/posts/hip-http2-using-docker/
https://noncombatant.org/2014/03/03/downloading-software-saf...
(after what I think was a long time, the actual download links themselves are now HTTPS, although they're all still served -- along with the signatures -- from an HTTP page)
I'm certainly not going to defend the idea that HTTPS is enough authentication for software installations (I'm writing an article related to software transparency), but there's a pretty big bootstrap problem and infrastructure gap right now.
If you have ensured that you're getting the right instructions, and those instructions supply the right fingerprint, then you can be sure that you have the right fingerprint.
[0] https://tools.ietf.org/html/draft-ietf-acme-acme-02
[1] https://tools.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-02....
All due respect to the client authors, but only a few clients are good. Many are very poorly written, which I do not trust for security. I believe the cause is not having a clear, short, standard modern spec.
Right, but even though the protocol is simple, there are pretty much always subtleties and potential ambiguities that need to be resolved by the spec so that one can write good implementations.
> I believe the [problem] is not having a clear, short, standard modern spec.
The IETF ACME draft spec is (like many IETF specs) clear, short, standard, and modern. The entire document is only 50 pages (fewer if you reduce the font size), and (from skimming the ToC) the last ~10 of those pages are largely optional material for someone who's just reading to implement the protocol. That document shouldn't take you more than an hour to read and digest.
If you've never actually read an IETF spec they can be intimidating, but -if you're a programmer, network guy, or backend web dev- you really, REALLY owe it to yourself to learn how to read them:
* Use the IETF's HTML RFC viewer rather than the plain text viewer.
* Until you become familiar with the way IETF standards documents are written, don't skim! They're generally information-dense documents that do NOT repeat themselves.
* Start from the beginning of the document and read through the end.
* If the spec references another document, and then starts to talk about things from that document that you don't understand and can't figure out, go read the relevant parts of the referenced document.
* If the spec starts presuming knowledge of things that you're sure it hasn't mentioned yet, backtrack a bit... you probably overlooked something.
* The ASCII-art diagrams present in some specs aren't there for fun; they're important information.
In regards to shorter documents, I'm not sure what you're looking for... just a listing of the HTTP conversations and their payloads?
Thanks for the advice, but it's not that I don't understand how to read it, it's that I can tell other devs don't understand it despite the good intentions of the authors.
Plenty of good clients are written for plenty of other tools, based on a much more straightforward call-and-response API spec. For example, the Hashicorp tools have a simple spec and proper clients in many languages.
On top of that, if you're using a programming language that's at least close to mainstream, there's a very good chance someone has already written a library which handles most of the nitty-gritty details of ACME. As an example, this is all the code you need with the acme-client ruby gem in order to solve a http-01 challenge and get a cert (slightly abbreviated):
require 'acme/client'
client = Acme::Client.new(private_key: private_key, endpoint: endpoint)
registration = client.register(contact: 'mailto:contact@example.com')
registration.agree_terms
authorization = client.authorize(domain: 'example.org')
# serve challenge.filename with content challenge.file_content
challenge.request_verification
# loop/sleep until challenge.verify_status == 'valid'
csr = Acme::Client::CertificateRequest.new(names: ['example.org'])
certificate = client.new_certificate(csr)
# certificate.to_pem contains your signed cert. done!Otherwise mail is sent to the owner of the crontab.
I'd agree that a hint regarding MAILTO= in the crontab file would be neat.