mirror of
https://github.com/certbot/certbot.git
synced 2026-01-26 07:41:33 +03:00
66 lines
2.2 KiB
Plaintext
66 lines
2.2 KiB
Plaintext
Database structure and procedures for the CA server
|
|
===================================================
|
|
|
|
This is information about how sessions and their progress are
|
|
represented inside the Redis database and what daemons should do
|
|
to advance the progress of a session.
|
|
|
|
Note that all values in Redis are normally stored as strings,
|
|
so references to "int" mean that the value in the database should
|
|
be INTERPRETED as an integer, not that it is natively stored as
|
|
one.
|
|
|
|
|
|
Sessions:
|
|
---------
|
|
|
|
hash: sessionid, "created" → int
|
|
sessionid, "live" → "True", "False"
|
|
sessionid, "csr" → str
|
|
sessionid, "state" → str
|
|
sessionid, "challenges → int
|
|
sessionid, "cert" → str
|
|
|
|
list: session:names → str
|
|
|
|
|
|
Challenges:
|
|
-----------
|
|
|
|
hash: sessionid:n, "challtime" → int
|
|
sessionid:n, "type" → int
|
|
sessionid:n, "name" → str
|
|
sessionid:n, "satisfied" → "True","False"
|
|
sessionid:n, "failed" → "True","False"
|
|
sessionid:n, "data" → str # This is problematic.
|
|
|
|
|
|
Queues:
|
|
-------
|
|
|
|
list: active-requests
|
|
list: pending-makechallenge
|
|
list: pending-testchallenge
|
|
list: pending-issue
|
|
list: pending-done
|
|
|
|
|
|
Daemons should FIRST pop sessions from a queue (and check whether the
|
|
thing that was pending has already been done?); then do the thing that
|
|
was pending; then change the session's state to the next state; then
|
|
push the session ID onto the next queue.
|
|
|
|
If the server crashes, then upon reinitalization the server can go
|
|
through everything in active-requests and push it onto the appropriate
|
|
pending-whatever queue for its state if it isn't already in that queue.
|
|
|
|
How do sessions get removed from the pending-done queue? (The server
|
|
can tell when it's told a client about a certificate issuance, but not
|
|
whether the client has received the good news.) Do we need to have
|
|
clients send a "thanks" message to let the server know that they've
|
|
received the cert? This could still lead to cases where the client has
|
|
received a cert but the CA never finds out about it because the client
|
|
crashes or goes offline afterward. However, without the acknowledgement
|
|
we could have the opposite problem (the client hasn't gotten a cert, but
|
|
the CA thinks it has).
|