| 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.
(cherry picked from commit 875764b07f937fc599e2e62c667e7b811ddc2ed3)
|
|
(cherry picked from commit 71d6d0fe31db13f4ddf5c75209b9bba88a1e0a32)
|
|
* install_certificate() code path handles private_key=None &
key_passphrase=None OK already
* file and console output paths will error trying to encode None as a key
* This is only an issue for a couple of the generate_*_sign() functions,
where having a null private key is possible
* Self-signing and CA creation always generate a private key
* Certreqs will generate a private key if not already provided
* Do not prompt for a private key passphrase if we aren't giving back a
private key
(cherry picked from commit d2cf8eeee9053d04f34c5e8a22373290d078ab37)
Co-authored-by: Andrew Topp <andrewt@telekinetica.net>
|
|
This fixes (for and ACME generated certificate)
vyos@vyos:~$ show pki certificate vyos fingerprint sha512
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/pki.py", line 1081, in <module>
show_certificate_fingerprint(args.certificate, args.fingerprint)
File "/usr/libexec/vyos/op_mode/pki.py", line 934, in show_certificate_fingerprint
print(get_certificate_fingerprint(cert, hash))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/vyos/pki.py", line 76, in get_certificate_fingerprint
fp = cert.fingerprint(hash_algorithm)
^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'fingerprint'
After the fix:
vyos@vyos# run show pki certificate vyos fingerprint sha256
10:2C:EF:2C:DA:7A:EE:C6:D7:8E:53:12:F0:F5:DE:B9:E9:D0:6C:B4:49:1C:8B:70:2B:D9:AF:FC:9B:75:A3:D2
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
* 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vyos@vyos# run generate pki wireguard key-pair install interface wg10
"generate" CLI command executed from config session.
Generated private-key was imported to CLI!
Use the following command to verify: show interfaces wireguard wg10
Corresponding public-key to use on peer system is: 'hGaWcoG7f+5sPAUY/MNQH1JFhsYdsGTecYA9S2J8xGs='
vyos@vyos# run generate pki wireguard preshared-key install interface wg10 peer vyos
"generate" CLI command executed from config session.
Generated preshared-key was imported to CLI!
Use the following command to verify: show interfaces wireguard wg10
vyos@vyos# show interfaces wireguard wg10
+peer vyos {
+ preshared-key OwTALZy8w6VIBMxUwbOv6Ys7QMyhrtY4aw+0cUjmmCw=
+}
+private-key 0Pu95CejvCUCCwrTW39TCYnitESWAdIIFTVJb7UgxVU=
[edit]
|
|
|
|
|
|
|
|
|
|
|
|
filenames
|
|
Also renames peer pubkey to public-key for consistency
|
|
|
|
|
|
|
|
|
|
|
|
|
