Domain server ACME client with custom Web UI. #1540
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
does not compile
General coding style changes (incomplete) API changed to support asynchronous operation with callbacks (incomplete) Error handling improvements (incomplete) Curl replaced with Qt (complete)
successfully ordering a certificate and receiving an http challenge.
API changed to support asynchronous operation with callbacks (complete) Curl replaced with Qt (complete) General coding style changes (incomplete) Error handling improvements (incomplete) A certificate successfully generated by manually completing the http challenge.
along with a short self-check before continuing with verification.
Certificate files and client key stored in application data path by default, Trusted CA file is made optional.
Conflicts: .gitmodules
namark
force-pushed
the
ssl-acme-client-part2
branch
from
66a8044
to
aedbd37
Compare
with simple directory url configuration functionality.
Also reporting status on errors and HTTP API enabled regardless of "enabled" setting.
|
The following links are available: build (ubuntu-18.04, full)
build (macOS-10.15, full) build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
|
The following links are available: build (macOS-10.15, full) build (ubuntu-18.04, full)
build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
ctrlaltdavid
requested changes
Apr 19, 2022
| } | ||
|
|
||
| void operator()(acme_lw::Response) const { | ||
| // TODO: check content |
| setError(status["certificate"], "invalid", { | ||
| {"message", message} | ||
| }); | ||
| // TODO: report a proper error, IO error, bad certificate etc |
|
The two TODOs @ctrlaltdavid pointed out are not critical, they're just meant to improve diagnostics of some rare errors, so I think it's fine to merge. I'll address them over time, whenever I come back to this to do something more substantial. |
|
The following links are available: build (macOS-10.15, full) build (ubuntu-18.04, full)
build (windows-2019, full) build (self-hosted_debian-11_aarch64, full)
|
ctrlaltdavid
approved these changes
Apr 25, 2022
ctrlaltdavid
added
CR Approved
namark
changed the title
|
The following links are available: |
|
Tested the second scenario (Generating a certificate for an IP) on Windows 11 Build 22621. Worked correctly. |
digisomni
added
QA Approved
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #1456
Web UI look and feel improvementsWeb UI status checksThis PR includes some functional improvements to the ACME client, and a custom interactive WEB UI for configuring it. The UI is written in plain JS and HTML to be independent of the rest of the settings panel, and to make it easier to convert to any other framework. It's available under SSL/ACME Configuration in the settings panel, or directly under http://localhost:40100/ssl-acme-client/. It communicates through HTTP with domain server using the settings.json API and a new API for uploading files and interacting with the ACME client; and with ACME server to retrieve some server specific information like terms of service, or authentication information. The UI has two major sections "Automatic Management" and "Certificate Paths".
Under certificate paths the directory and file names for certificate, its key and optional trusted authority list can be specified and local files selected for upload. All settings are submitted and files uploaded using the "Save Settings" button at the bottom. There is also a "Reset Certificate" button that will simply delete the certificate and its key (useful when automatic management is enabled to force a new certificate to be generated).
The bulk of the functionality of the client is in the automatic management, where, once enabled, the following settings should become visible:
Once everything is configures and settings are saved with automation enabled, the ACME client will attempt to create a certificate, or if one already exists - schedule a renewal. The Status checkbox will show a text area with JSON formatted status of the process. The "Restart Client" button will restart the ACME client without restarting the whole server. In combination with the "Reset Certificate" button it can be used to manually force the certificate to be regenerated. It can also be useful to manually retry a failed renewal.
Renewals are schedule at 2/3 of the expiry duration of the certificate (typical duration is 90 days, so they will be scheduled 30 days in advance). If the renewal (or certificate generation in general) fails it will be scheduled to repeat in 24 hours.
Even if automation is disabled the ACME client will perform renewal checks every 24 hours and notify other subsystems of the domain server (currently just WebRTCSignalling server) if the certificate was renewed. This allows the user to use third party clients for automation (assuming certificate paths properly configured).
Note on Certificates for IP addresses: In the Domains section IP addresses(both v4 and v6) can be specified instead of domain names. Generating certificates for IP addresses is an extension of the ACME standard that this client implementation supports, but neither Let's Encrypt not ZeroSSL do unfortunately. This might change in the future, but in the meanwhile ZeroSSL REST API is available as CA directory option for that use case, even though it's not an actual ACME directory endpoint.
Some testing scenarios
These assume domain server (and assignment clients) are set up on a public server with port 80 available for HTTP hosting and that the Web SDK example is built and hosted locally.
Generating a certificate for a domain name:
Generating a certificate for an IP: