glatzert
error on requesting cert from appliance acme client ...
thanks for this amazing project ... already created dokumentation internal for an project offering to one of our clients.
for testing they want to bind windows, linux and some appliances to this systems. for this i've created an simple test environment and windows/linux working fine.
for appliance testing i got the following error message in the logfile: 20240729.json
appliance configuration:
Hey there, it's calling "set account" - a function which I have not bothered to implement, yet. I'll fix that - it's not complicated (alas not super useful, since most accounts will just be discarded and recreated)
https://github.com/glatzert/ACME-Server-ADCS/releases/tag/V1.10.0 should allow setting account details
will come back to you in some time. will test it =) thx so much for your fast response
seams not working for the appliance, but on configuration page on appliance i've seen some more details:
5.3.1. Preconditions
An additional license must be obtained to be able to use the ACME feature - contact your account manager.
Any virtual host using ACME must be accessible by the CA over TLS on port 443
The appliance must be able to connect defined CA AMCE API endpoint (DNS & routing)
5.3.2. Limitations
Only challenge type TLS-ALPN-01 is supported.
Other ports than 443 for virtual hosts are not supported by the ACME protocol
Wildcard certificates are not supported (requires DNS challenge)
EAB or other authorization means are not supported
according to the log created it connects on http for the target ... {"@t":"2024-07-31T19:31:10.2651726Z","@m":"Attempting to validate challenge 5YYp7cvupUudO-2dA6bkaQ (http-01)","@i":"c8ee51d3","SourceContext":"TGIT.ACME.Protocol.Services.Http01ChallangeValidator"} {"@t":"2024-07-31T19:31:10.2720818Z","@m":"Start processing HTTP request "GET" "http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS"","@i":"338f1c77","HttpMethod":"GET","Uri":"http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS","EventId":{"Id":100,"Name":"RequestPipelineStart"},"SourceContext":"System.Net.Http.HttpClient.Http01ChallangeValidator.LogicalHandler","Scope":["HTTP GET http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS"]} {"@t":"2024-07-31T19:31:10.2728588Z","@m":"Sending HTTP request "GET" "http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS"","@i":"2e7ac211","HttpMethod":"GET","Uri":"http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS","EventId":{"Id":100,"Name":"RequestStart"},"SourceContext":"System.Net.Http.HttpClient.Http01ChallangeValidator.ClientHandler","Scope":["HTTP GET http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS"]} {"@t":"2024-07-31T19:31:10.3248019Z","@m":"Received HTTP response headers after 42.4823ms - 404","@i":"f0742c1f","ElapsedMilliseconds":42.4823,"StatusCode":404,"EventId":{"Id":101,"Name":"RequestEnd"},"SourceContext":"System.Net.Http.HttpClient.Http01ChallangeValidator.ClientHandler","HttpMethod":"GET","Uri":"http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS","Scope":["HTTP GET http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS"]} {"@t":"2024-07-31T19:31:10.3254690Z","@m":"End processing HTTP request after 57.6311ms - 404","@i":"7656b38e","ElapsedMilliseconds":57.6311,"StatusCode":404,"EventId":{"Id":101,"Name":"RequestPipelineEnd"},"SourceContext":"System.Net.Http.HttpClient.Http01ChallangeValidator.LogicalHandler","HttpMethod":"GET","Uri":"http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS","Scope":["HTTP GET http://linux.jalinski.local/.well-known/acme-challenge/DiY2TOxwaiG_bVvqdEZY_oEzgqHKv-5FmTNVG-lzdeC_A3j_8GMBUlTsG42WWwaS"]} {"@t":"2024-07-31T19:31:10.3303679Z","@m":"Could not load challenge response: Got non 200 status code: NotFound","@i":"57c76157","SourceContext":"TGIT.ACME.Protocol.Services.Http01ChallangeValidator"}
its possible to make it possible to setup the connection type? something like choose between http and https?
best regards + thanks for the support
The log and the docs sort of contradict each other: The docs say only TLS-ALPN-01 is supported (that's a possible type of challenge, ACME-ADCS currently does not support that type), but then it requests the server to go forward with the http-01 challenge, which it does answer with 404.
I'll take a look into TLS-ALPN-01 and how much effort it would take, to implement it as well.
TLS-ALPN-01 (https://www.rfc-editor.org/rfc/rfc8737) seems feasable - I'll look into it during the weekend
If you're "brave" you can get a look into the yet untested TLS-ALPN-01 support - I'll setup a test environment tomorrow and run the code through it myself
TLS-ALPN-01 support now has been successfully run through a test process, that's based on a local test-server.
Hello Thomas, thanks for the implementation. I am currently testing and in consultation with the software supplier.
I was able to test TLS-ALPN-01 on the client side, but there is still an error on the appliance. However, that is definitely the fault of the manufacturer.
Thank you very much
best regards
Hello,
tested it now on appliance and linux ... http01 works, but alpn didnt work (see attached log files) linux_acme.sh_debug_alpn.txt linux_acme.sh_debug_http01.txt
attached is the windows log during the call 20240807.json
this matches to the error which i currently get on the appliance.
could you please check it?
with best regards
Thanks for the feedback, I possibly identified the error with tls-alpn-01 - I (for some reason) expected the challenge response to be UrlBase64Encoded, when in fact it's not. 2.0.2-r1 should address that - I also adjusted the test-server, that now does not urlencode the extension content anymore.
... that was kind of embarrasing. I shoud've let the test run to end to see a missing ! 😆 Please use -r2
currently windows and linux clients working perfect. the appliance will recognize it now but comes with an error about the rsa which its not able to find. i've already contacted the company of the appliance because as 2 environment could work perfectly with the tool i asume its an "custom" mod_md apache implementation ... if you want, i can for sure share the error which comes in the appliance ...
If the server can help solving the problem (within protocol specs), I'm happy to help, so yes- please share the error
Hello Thomas, unfortunly it doesnt work. i've talked with the appliance guys and they found some but nothing which seams working for them. they ask if i can ask you about experience with the mod_md module which they used ...
https://github.com/icing/mod_md
they currently thinking about implement another option like an batch tool but recommend to ask if you have some knowledge about using the acme tool with mod_md as backend system.
with best regards Werner
Are you able to provide a whole log of both the ACME and the Appliance? Email will do - I'd like to understand the process and when it fails.
Regarding mod_md, I unfortunately do not have more knowledge than their documetation. But since that reads rather solid about the certificate process, I'd assume it to be built properly.
What comes to mind with ACME Server is the polling time. Currently the issuance and validation processes might take a minute to complete - some implementations aren't that patient (seen in certbot) so it might be a problem. You could try giving those rerun timers a smaller value.
Besides the error described here, there might be an error state, when clients wanted to use set-account - it's been resolved