Commit 4869b6c6 authored by Adrien Dorsaz's avatar Adrien Dorsaz

Update documentations and clean non used file / code

parent ecfe88c7
Pipeline #30 passed with stage
in 3 minutes and 48 seconds
sudo: required
dist: trusty
language: python
- "2.7"
- "3.3"
- "3.4"
- "3.5"
- "nightly"
- sudo apt-get install fuse
- sudo chmod a+r /etc/fuse.conf
- pip install -r tests/requirements.txt
- coverage run --source ./ --omit ./tests/ -m unittest tests
- coveralls
The MIT License (MIT)
Copyright (c) 2015 Daniel Roesler
Copyright (c) 2016 Adrien Dorsaz
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
......@@ -5,7 +5,7 @@
This is a tiny, auditable script that you can throw on your server to issue
and renew [Let's Encrypt]( certificates with DNS
Since it has to have access to your private ACME account key and the
rights to update the DNS records of your DNS server, this code has been designed
......@@ -13,7 +13,7 @@ to be as tiny as possible (currently less than 250 lines).
The only prerequisites are python (especially the dnspython module) and openssl.
Note: this script is a fork of the [acme-tiny project](
which uses ACME HTTP verification to create signed certificates.
......@@ -88,7 +88,7 @@ openssl req -new -sha256 -key domain.key -subj "/" > domain.csr
openssl req -new -sha256 -key domain.key -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\,")) > domain.csr
### Step 3: Make your DNS server allow dynamic updates
### Step 3: Make your DNS server allows dynamic updates
You must prove you own the domains you want a certificate for, so Let's Encrypt
requires you host some DNS resource records.
......@@ -106,9 +106,9 @@ The configuration of the script will need:
* the address and the port of the DNS server
The simplest way to configure the script is to copy the `example.ini` file
from this repository and update the values as needed.
from this repository and update values as needed.
**Be careful! Set permissions correctly on your configuration file, because
**Be careful! Set read permissions correctly on the configuration file, because
it will contain the key authorized to modify your DNS configuration !**
### Step 4: Get a signed certificate!
# How to test acme-tiny
# How to test acme-dns-tiny
Testing acme-tiny requires a bit of setup since it interacts with other servers
Testing acme-dns-tiny requires a bit of setup since it interacts with other servers
(Let's Encrypt's staging server) to test issuing fake certificates. This readme
explains how to setup and test acme-tiny yourself.
## Setup instructions
1. Make a test subdomain for a server you control. Set it as an environmental
variable on your local test setup.
* On your local: `export`
2. Generate a shared secret between your local test setup and your server.
* `openssl rand -base64 32`
* On your local: `export TRAVIS_SESSION="<random_string_here>"`
3. Copy and run the test suite mini-server on your server:
* `scp`
* `ssh`
* `export TRAVIS_SESSION="<random_string_here>"`
* `sudo`
4. Install the test requirements on your local (FUSE and optionally coveralls).
* `sudo apt-get install fuse`
* `virtualenv /tmp/venv`
* `source /tmp/venv/bin/activate`
* `pip install -r requirements.txt`
1. Setup environment variables:
* Read top of, all environnement variables used are defined there (top of file).
* These variables corresponds to the configuration file you have to do when using in production.
* If you don't own the gitlab project, you can set them on your build/test machine:
* Otherwise, you have to use your gitlab project to define environment variables for gitlab runners.
2. Install the test requirements on your build/test machine (automated by .gitlab-ci.yml for gitlab runners).
* `cd /path/to/acme-dns-tiny`
* `pip install --user -r tests/requirements.txt`
5. Run the test suit on your local.
* `cd /path/to/acme-tiny`
* `coverage run --source ./ --omit ./tests/ -m unittest tests`
## Why use FUSE?
Acme-tiny writes the challenge files for certificate issuance. In order to do
full integration tests, we actually need to serve correct challenge files to
the Let's Encrypt staging server on a real domain that they can verify. However,
Travis-CI doesn't have domains associated with their test VMs, so we need to
send the files to the remote server that does have a real domain.
The test suite uses FUSE to do this. It creates a FUSE folder that simulates
being a real folder to acme-tiny. When acme-tiny writes the challenge files
in the mock folder, FUSE POSTs those files to the real server (which is running
the included, and the server starts serving them. That way, both
acme-tiny and Let's Encrypt staging can verify and issue the test certificate.
This technique allows for high test coverage on automated test runners (e.g.
* `cd /path/to/acme-dns-tiny`
* `coverage run --source ./ -m unittest tests`
......@@ -55,24 +55,6 @@ class TestModule(unittest.TestCase):
self.assertIsInstance(result, ValueError)
self.assertIn("Key too small", result.args[0])
# def test_invalid_domain(self):
# """ Let's Encrypt rejects invalid domains """
# try:
# result = acme_dns_tiny.main([CONFIGS["invalidCSR"].name])
# except Exception as e:
# result = e
# self.assertIsInstance(result, ValueError)
# self.assertIn("Invalid character in DNS name", result.args[0])
# def test_nonexistant_domain(self):
# """ Should be unable verify a nonexistent domain """
# try:
# result = acme_dns_tiny.main([CONFIGS["inexistantDomain"].name])
# except Exception as e:
# result = e
# self.assertIsInstance(result, ValueError)
# self.assertIn("urn:acme:error:connection", result.args[0])
def test_account_key_domain(self):
""" Can't use the account key for the CSR """
......@@ -86,4 +68,4 @@ class TestModule(unittest.TestCase):
if __name__ == "__main__":
# delete account key registration at end of tests
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment