| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When using an ACME based certificate with VyOS we provide the necessary PEM
files opaque in the background when using the internal tools. This however will
not properly work with the CA chain portion, as the system is based on the
"pki certificate <name> acme" CLI node of a certificate but CA chains reside
under "pki ca".
This adds support for importing the PEM data of a CA chain issued via ACME into
the "pki ca AUTOCHAIN_<name> certificate" subsystem so it can be queried by
other daemons. Importing the chain only happens, when the chain was not already
added manually by the user.
ACME certificate chains that are automatically added to the CLI are all prefixed
using AUTOCHAIN_certname so they can be consumed by any daemon. This also adds
a safeguard when the intermediate CA changes, the referenced name on the CLI
stays consitent for any pending daemon updates.
|
|
Add CLI commands
Add config
Add conf_mode
Add systemd config
Add stunnel smoketests
Add log level config
|
|
Commit 9f9891a2099 ("pki: T6241: Fix dependency updates on PKI changes") added
a print() statement which notified the users about the subsystems which got
supplied with an updated certificate.
Example:
> PKI: Updating config: interfaces openvpn vtun0 tls certificate openvpn_vtun0
> PKI: Updating config: interfaces openvpn vtun0 tls ca_certificate openvpn_vtun0_1
This is an informational message which should maybe (if needed) be sent to
syslog. But the main issue is that CLI paths are mangled (- to _) which makes
the about print output wrong and could potentially confuse users.
Statement has been commented to be re-enabled for debugging.
|
|
The haproxy reverse proxy was not reloaded/restarted with the new SSL
certificate(s) after a change in the PKI subsystem. This was due to missing
dependencies.
|
|
|
|
|
|
|
|
set pki openssh rpki private key ...
set pki openssh rpki public key ...
set pki openssh rpki public type 'ssh-rsa'
|
|
hyphen (-)
When testing for changed PKI certificates using node_changed(), we should not
use key_mangling=('-', '_'), as this will make certificate updates with a hypen
not possible.
|
|
This fixes a priority inversion when doing initial certificate commits.
* pki subsystem is executed with priority 300
* vti uses priority 381
* ipsec uses priority 901
On commit pki.py will be executed first, detecting a change in dependencies
for vpn_ipsec.py which will be executed second. The VTI interface was yet not
created leading to ConfigError('VTI interface XX for site-to-site peer YY does
not exist!')
The issue is caused by this new line of code in commit b8db1a9d7ba ("pki:
T5886: add support for ACME protocol (LetsEncrypt)") file src/conf_mode/pki.py
line 139 which triggers the dependency update even if a key is newly added.
This commit changes the "detection" based on the cerbot configuration on disk.
|
|
The "idea" of this PR is to add new CLI nodes under the pki subsystem to
activate ACME for any given certificate.
vyos@vyos# set pki certificate NAME acme
Possible completions:
+ domain-name Domain Name
email Email address to associate with certificate
listen-address Local IPv4 addresses to listen on
rsa-key-size Size of the RSA key (default: 2048)
url Remote URL (default:
https://acme-v02.api.letsencrypt.org/directory)
Users choose if the CLI based custom certificates are used
set pki certificate EXAMPLE acme certificate <base64>
or if it should be generated via ACME.
The ACME server URL defaults to LetsEncrypt but can be changed to their staging
API for testing to not get blacklisted.
set pki certificate EXAMPLE acme url https://acme-staging-v02.api.letsencrypt.org/directory
Certificate retrieval has a certbot --dry-run stage in verify() to see if it
can be generated.
After successful generation, the certificate is stored in under
/config/auth/letsencrypt. Once a certificate is referenced in the CLI (e.g. set
interfaces ethernet eth0 eapol certificate EXAMPLE) we call
vyos.config.get_config_dict() which will (if with_pki=True is set) blend in the
base64 encoded certificate into the JSON data structure normally used when
using a certificate set by the CLI.
Using this "design" does not need any change to any other code referencing the
PKI system, as the base64 encoded certificate is already there.
certbot renewal will call the PKI python script to trigger dependency updates.
|
|
We will use _ as CLI level divider. The XML definition filename and also
the Python helper should match the CLI node.
Example:
set interfaces ethernet -> interfaces_ethernet.xml.in
set interfaces bond -> interfaces_bond.xml.in
set service dhcp-server -> service_dhcp-server-xml.in
|
|
|
|
* T5195: move run, cmd, call, rc_cmd helper to vyos.utils.process
* T5195: use read_file and write_file implementation from vyos.utils.file
Changed code automatically using:
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import read_file$/from vyos.utils.file import read_file/g' {} +
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import write_file$/from vyos.utils.file import write_file/g' {} +
* T5195: move chmod* helpers to vyos.utils.permission
* T5195: use colon_separated_to_dict from vyos.utils.dict
* T5195: move is_systemd_service_* to vyos.utils.process
* T5195: fix boot issues with missing imports
* T5195: move dict_search_* helpers to vyos.utils.dict
* T5195: move network helpers to vyos.utils.network
* T5195: move commit_* helpers to vyos.utils.commit
* T5195: move user I/O helpers to vyos.utils.io
|
|
|
|
|
|
|
|
|
|
|
|
|
