In another thread I suggested that the explanations returned by the Let’s Encrypt CA in response to challenge failures can be pretty terse, and that web-based clients might be a position to perform greater challenge validation themselves in response to a failed challenge (to try to further diagnose why it might have failed).
Do you, as web client developers, think this is a common problem and that you might be in a position to do anything about it? For example, could you imagine trying to validate the challenge either from the user’s web browser or from your server and then telling the user about things that appear not to have worked properly from that vantage point?
Since it doesn’t have access to private keys, it cannot sign requests without the whole copy-sign-paste interface. So any diagnostics/retries that include sending authenticated requests will be the same friction as just starting over.
CORS prevents the website from requesting the server’s test file to make sure it’s being served properly. I do make the link that the user can click to see if it is valid, but I can’t do much beyond that. Also, gethttpsforfree is unhosted (i.e. just a static file, that can be downloaded and opened locally), so I can’t get around CORS (even though other web clients might).
Hope that helps! Gethttpsforfree.com is just a barebones web client for quick one-off certs, so complex diagnostics probably isn’t in scope for the project.
Hope that helps! Gethttpsforfree.com is just a barebones web client for quick one-off certs, so complex diagnostics probably isn't in scope for the project.
Absolutely NOT! I like your client a lot
I was able to modify it in a straight forward way to Support PowerShell commands for windows so don't sell yourself short
This is a good question - with the approach of zero-knowledge for the web app, where there is no data sent to the backend, it is not something that might happen automatically. However, there could be an option to offer an assistance when some specific error code is returned, in which case the user must give consent to send error information and the domain back to the server to attempt some extended diagnostics.
I remember thinking about that at one point, though the amount of actual mails about some errors returned by LE servers is actually quite low (possibly because of the way the process is structured). There could be some improvements made of course - for example sometimes it is quite clear that returned content is a HTML response and not the verification file, so there could be some explanation given along the lines of what's wrong and what to check.
From server-side perspective there could be a more specific set of codes sent to assist with diagnostics and tell one problem from another without relying on the text of an error message itself. Additionally there are limitations I noticed time ago (though not sure if I submitted those at the time as an issue).
For example, if you call 'new-reg' with a key that is already registered, you cannot get a proper 'reg' resource URL. The 409 response returned in that case sends an 'Access-Control-Expose-Headers' header set to 'Link, Reply-Nonce'. However, the 'reg' resource URL is sent in Location and Link does not seem to be present.
If I'm not mistaken, fixing this looked rather trivial when I checked it at the time (adding Location to Access-Control-Expose-Headers value in wfe/web-front-end.go and wfe/web-front-end_test.go or providing the Link header with that value), but perhaps there was a reason for this particular system behaviour?
NB: This is posted quite early in the morning, so if there are typos or odd parts in the post - those will be fixed later
Thanks for the answers, @diafygi and @leader ; that makes sense about why this is difficult to do given the concern that both of these projects are showing for users’ privacy.
