You are here
my topic in my account-application Wed, 2023/07/19 - 21:59
concerning the Lamp-VM 17.1 and the core-VM 18Orc1.
See also post https://www.turnkeylinux.org/forum/support/sat-20221126-1937/lets-encryp.... I nearly encounter the same problem. (But in that post it didn´t need be solved.)
---
my Question could have been forgotten or deferred for work to be done in the programming. Obviously the latter must have been the case, as for the core-VM a new Version 18Orc1 has been released, which nearly solves the problem (see at the end). But one after another.
A) Concerning the Lamp-VM Ver. 17.1 I found a workaround avoiding the use of confconsole:
because I could not install snap für auto-Installation of certbot (snap endet up with an error) and also could not install docker using the apt repository in order to use the docker-based function of certbot, I installes docker as described in https://docs.docker.com/engine/install/debian/
by installing the five single docker components with dpkg -i . that worked fine and I was able to start certbot using the following command:
docker run -it --rm --name certbot \
-v “/etc/letsencrypt:/etc/letsencrypt” \
-v “/var/lib/letsencrypt:/var/lib/letsencrypt” \
-v “/var/log/letsencrypt:/var/log/letsencrypt” \
-v “/var/www:/var/www” \
-v “/etc/letsencrypt/live:/etc/letsencrypt/live” \
certbot/certbot certonly
Turned out to be essential, also to bind the webroot and the certificate-storage-directories as a docker-volume, so that docker could within its container map the server-directory and store the certificate at the appropriate place. The domain-cert also containing 2 new subdomain have been produced. (by the way: to reach the web from my laptop that contained the VM I had to edit the hosts-files on windows and in the VM /etc/hosts to get to know them the domain and local target IPs für the VM).
letsencrypt established a directory-structure unter /etc/letsencrypt that also comprised the hook-scripts for auto-renewing.
Following that I avoided to use the combined version of a "cert.pem" als delivered by turnkey by default, so that I hat not to copy and paste the LE-Zertificates privkey.pem and fullchain.pem to a new cert.pem for storing under /etc/ssl/private manually.
Instead, in /etc/webmin I linked ( "ln -s <Source-certificate under LE> <Target-Linkname under /etc/webmin>") to privkey.pem for establishing miniserv.pem from privkey.pem and miniserv.crt from fullchain.pem. For the latter it is irrelevant if you use the new ending .crt while linking to .pem as both are the same txt-format. the source-path under LE ist /etc/letsencrypt/live/<domain>/ <files...>.pem.
in /etc/ssl/private I deleted the defauld "cert.pem" which I don´t use in that VM any longer so I can link directly to the appropriate LE-pems. It was obviously used in
/etc/apache2/mod-enabled/ssl.conf
and in /etc/stunnel/webmin.conf and shellinabox.conf.
In these places I replaced the links to /etc/ssl/private/cert.pem by in all places two Links pointing to my LE-places as above
(ssl.conf:
# Default certificate file to use (provided by TurnKey)
SSLCertificateFile /etc/letsencrypt/live/<domain>/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<domain>/privkey.pem
in webmin.conf and shellinabox.conf:
; Certificate/key is needed in server mode and optional in client mode
; cert = /etc/ssl/private/cert.pem
key = /etc/letsencrypt/live/<domain>/privkey.pem
cert = /etc/letsencrypt/live/<domain>/fullchain.pem
for use of apache2 it is also ok, to cite the single cert.-files as they are found in LE:
/etc/apache2/sites-enabled/000-default.conf:
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/<domain>/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/<domain>/fullchain.pem
ServerAdmin webmaster@localhost
DocumentRoot /var/www
SSLProtocol +TLSv1.2 +TLSv1.3
SSLCertificateKeyFile /etc/letsencrypt/live/<domain>/privkey.pem
SSLCACertificateFile /etc/letsencrypt/live/<domain>/fullchain.pem
</VirtualHost>
A further usage of the turnkey-original-cert.pem I could not discover -
and anything works fine with SSL. The certificate is known in the browser-screen as trusted.
B) Concerning the core-VM Ver. 18.Orc1 (pure - whithout any workarounds or installations):
it might be somewhat slightly differently constructed so I had did not succed just to copy and paste the solution as above to it- I would have to work on to find my own thought-faults - but: I found and I appriciate especially, that the confconsole-function for SSL by letsencrypt has been corrected, so that does not seem to be needed:
I could start LE by confconsole, type-in my domains and - GOT NEW SSL-Certificates.
They were stored in a dehydrated-structure under /var/lib/dehydrated. Under /etc/ssl/private a new combined (see above - different from the one in LE) "cert.pem" has been stored to serve the needs of webmin et al. No need to replace the links in ssl.conf (and further on) by two seperate lings towards LE.
Everthing looks very nice.
One drop of tear remains:
The browser, trying to show webmin-screens, doesn´t seem to like it and says "I dont´t trust the certificate as it is invalid".
which just can´t be the fact: it has got a new validation-date as to Nov.1st. the dehydrated-structure and -files seem flawless.
What could I have failed to look at ?
...and I DO appeciate your being arouhouhound... :-)
the biggest guessable catastrophic beginner (BGCB)...
I´m so sorry - as I said my Intro has been lost: Just trying to get involved in technical system connections step by step and exploring anything what I need to get working tools run, that I could need without being a technician at all. There might be other people out there too who´d like to catch a step to insights.
Saying that, I admit I should not switch in short time between to much different specialists topics from non-technical areas to these topics and then again between different systems (VM1 / VM2) :(
As this is the CORE-Machine there is no installed Webserver for the domain and in the Lamp the cert. is trusted in connection with a webserver call from the public adress (naturally).
Please forget the last question concerning teardrops! It might be yours ;)
Every thing is fine!
Hi Klaus, apologies about our website...
Hi Klaus, apologies that our website bit you. As something of an aside, replacing our current website (inc new forums software) is relatively high on our todo list, but we're a small team with lots on, so it seems to take ages to get anything finished...
I've already started a proper reply to your post, but I just saw this new post and I wanted to do a quick response here.
Re Core, in our Let's Encrypt integration, we provide our own mini-server to server the HTTP challenges, so it should get certs the same as any other server - and all servers use that same method; regardless of which webserver the server uses. If you prefer certbot, then you'll need to install a webserver that it is compatible with. I'll respond in more detail to your issues specifically in my main response that is in progress.
Regarding your Webmin cert issue, if you are using certbot, that's expected. Certbot will know nothing of Webmin and won't consider restarting it. I imagine that certbot has support for hooks? Assuming so, you could write a hook script to restart Webmin when it updates certs. In the meantime and to test that I'm on the right track, please try restarting Webmin (v18.0+) or the specific stunnel@webmin service (v16.x/v17.x) to use the updated cert (our setup does that as part of the process). This should do the trick:
If that's still not right, please check the cert in your browser and copy/paste the cert info for me to inspect.
[Update] Oops, sorry it looks like I misread your post! It sounds like the webmin issue is resolved (although I suspect that if it was as per my suspicion, it required a restart - so if you are using certbot, then it will likely happen again once the certs get updated).
I'd be curious to understand what the actual issue is!?
I'm not 100% sure why it's occurring for you (and at least a similar issue for others), but the issue is either something local to your server/network (e.g. some routing or firewall issue), or is some sort of race condition in the code. I'm sure it's of very limited value to you, but FWIW it consistently "just works" for me!? (I set up 3 x v18.0 app testing builds yesterday and all 3 "just worked").
Assuming that your issue was the same as the thread that you point to, then for some reason, your server is giving a 400 error code when contacted by Let's Encrypt services. It should "just work" (although if you try a few times and it keeps failing, then you will be blocked for a period of time).
I have no idea why Dehydrated didn't work, but then certbot did. I'm purely speculating, but my guess is that it was some initial or intermittent issue (perhaps DNS propagation delay?) which caused the cert getting process to fail; and after trying a few times, then you got locked out. By the time you got certbot installed and set up, the DNS had properly propagated and the ACME block had been lifted (i.e. timed out).
As I noted above, another possibility is a race condition. Essentially a race condition is a timing problem, e.g. when things don't happen in quite the right order. We tend to use relatively low power systems (as most of our users are running in VMs of some sort - often with relatively limited resources). So I'd be interested to hear what sort of resources your server has. If it's a relatively high power machine, then that may explain it? (And if so, then will give me a lead to try to recreate the issue).
Hi Jeremy,
Hi Jeremy,
honestly thanks für your engagement in that topic! It´s right, my personal environment is not really ideal. Just sufficient for ad-hoc-usage of Web-Applications and servers in personally agreed situations to cover distance for collaboration with limited participants. And learning to understand whats going on with such systems. That´s what initial problems are good for. Especially when they are finally solved. The environment might have been one of the main causes. Next step were a permanent cloud-hosted solution with your systems.
And with a reliable system at the lastest state, especially with your latest Version 18 I won´t fiddle around trying "workarounds" for an actual specific situation that might just cause frictions while upgrading further on. But will use the build-in-solutions.
Thank you again
Klaus.
Add new comment