-
Notifications
You must be signed in to change notification settings - Fork 584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance CSR Autosigning (CA proxy, etc.) #5450
Comments
Updated the description with ongoing tasks. |
Updated TODO list: ca-proxy-2017-08-29.pdf |
Updated TODO list: ca-proxy-2017-08-30.pdf |
Ongoing tests. Cli commands, log messages and debug logs will change. Two Level ScenarioShould work as before, bonus: ticket less signing on the master. Ticket-less
Client disconnect:
Reconnect
Certificate is updated on disk and in-memory including a reconnect to re-establish the connection using the signed certificates. Ticket
Client wizard with ticket:
Master:
|
Three level clusterTicket basedMaster generates client ticket.
Client sends delayed request.
Satellite forwards request to the master.
Master signs the certificate request immediately, since it contains a valid ticket. If not, a warning is logged, i.e. the identity does not match or the ticket hash is invalid.
Satellite receives updated certificate for agent.
Client receives the certificate, stores it on disk and in memory. Disconnects the satellite to enforce valid SSL handshake and trusted relationship automatically.
|
Three level clusterTicket less delayed requestClient wizard
Satellite forward
Master stores the request but does nothing without ticket.
List and sign the request on the master:
Client is started and requests a new certificate from its parent node (satellite)
Satellite forwards the request
Master receives the request, signs and sends back to the satellite
Satellite stores the message
Satellite sees that the client requests certificate on reconnect:
Satellite sends the updated certificate to the client
Client receives the updated certificate, stores it, updates the SSL certificates at runtime and reconnects all endpoints.
The next time the connection is re-established, it is a trusted signed relationship.
On the satellite (we don't have an Endpoint object yet, but seeing this message means that the SSL handshake was successful).
|
Certificate renewalIf the client certificate will be expired in 30 days, the client will automatically request a new certificate based on the current signed trusted relationship. This is also true for certificates generated before 1.1.2017 to allow certificate updates with possible broken serials in #5511 |
Clients without connection to the parent nodeYou may run the node wizard command, but select to not connect to the master (or parent node). The wizard will tell you where to put the public CA certificate in order to start Icinga 2. You need to copy that manually from the master to let the parent node connect and do the certificate request thing. |
More loggingClient
Satellite
Master and Satellite
Signed certificate update
|
Examples: #5450 (comment) This also adds code comments where applicable.
Examples: #5450 (comment) This also adds code comments where applicable.
Multi-Master setupMaster 2 Setupmaster2 as satellite master1
master2
Agent setup through Master 2
Master 2
Master 1
Sign it on master 1
Master 2
Agent
|
User documentation for signing methods and the linux setups has been added. Technical documentation will be added tomorrow. Windows setup wizard depend on pending changes for the Windows wizard itself (tickets are coming). |
Examples: #5450 (comment) This also adds code comments where applicable. refs #5450
…s selected This also fixes the choice tree for connection-less questions and prevents empty tickets being stored on disk. refs #5450
…setups Better explanation for "CSR Auto-Signing" and a new term "On-Demand CSR Signing". The Linux setup now accompanies the user step by step on each question asked. The full table with all the details is moved to the bottom. TODO: The Windows setup wizard does not support connection-less or ticket-less requests yet. refs #5450
Description
Sponsored feature request.
Problem
Three level clusters where the clients should send their certificate signing requests to the master.
Clients need a direct connection to the CSR-Auto-Signing master. The satellites cannot forward the request.
Workarounds exist:
Possible Solutions
Clients sends a signing request to the parent endpoint, which forwards the signing request to the master.
The master answers the request, and sends back the signed certificate.
The satellite stores the received certificate and sends it back to the client once received.
This is an asynchronous operation and requires the client to reconnect (which it already does).
The SSL handshake will fail (self-signed certificate), but the parent node needs to send back
a signed certificate, if any.
Client <-> Satellite
Reconnect cycle. Store certificate in /var/lib/icinga2/pki (TODO)
Symlink /etc/icinga2/pki to /var/lib/icinga2/pki (Windows?) (TODO)
Satellite <-> Client
1.)
2.)
Client connects, have local cached signed certificate?
Send back
forward possible pki::RequestCertificate
CSR Master <-> Satellite
if request contains a ticket, always immediately answer
otherwise write unaccepted CSR to local "todo" cache (TODO, nice2have)
if there are accepted signed certificates for the connecting endpoint and child zones, send them back (TODO, nice2have)
Satellite <-> CSR Master
Housekeeping
Allow to purge obsolete requests. Best is a directory on disk which the user may control.
Problems
The client does not run as root, and cannot override /etc/icinga2/pki at runtime. Needs to store its
certificate in /var/lib/icinga2/pki
Ensure that the connecting client really is the one who should receive the certificate.
How about the
trusted-master.crt
fetch - this request needs to be proxied too.Additional Benefits
Optional Ticket
Make the ticket optional. CSRs on the master without a valid ticket are not automatically answered.
Instead, there is a CLI command available which allows to manually sign those requests (one by one, with certificate prompt similar to Puppet).
Master just sends signed certificates back to corresponding clients.
Design Draft
Storage
Migration is required, new certificates and requests will be stored here.
Inspired by https://docs.puppet.com/puppet/5.1/dirs_ssldir.html
Tasks
The text was updated successfully, but these errors were encountered: