DietPi-Banner | add letsencrypt certificate details

[gary2002]

Addition to check if a letsencrypt certificate exists and if so, print the certificate expiration details.

This can act as a simple check to see if letsencrypt certificates are updating over time.

[gary2002]

Many thanks. I finally got over the line ;-)

But I have learnt some useful GitHub tips and techniques.

Many thanks for your patience!!!

[MichaIng]

Looks good to me now. Only thing is that I'm not too happy with the date format:

Valid until 10-Jul-2023 @ 23:25:20

I'd prefer the common standard international format

Valid until 2023-07-10 23:25:20

But there is no way to change this in openssl, is it? At least I couldn't find an option. So closest we could do:

Valid until 2023-Jul-10 23:25:20

What do you think?

[MichaIng]

We talked on our meeting yesterday about the time format and agreed to prefer 2023-Jul-10 23:25:20 as being closest to the otherwise common international standard 2023-07-10 23:25:20. I adjusted the PR accordingly and added a little other minor coding updates, I hope you agree. Merging this.

[gary2002]

Very happy with that. Apologies for not responding sooner - busy day at work.

[MichaIng]

Jep no problem, I apologies for being a little impatient 😄. Want to get the open PRs all merged this weekend (aside of the two older banner related ones, which require significantly more work).

[gary2002]

I always use MMM in the date format to avoid ambiguity between days and months. I've found it necessary in projects I've worked on across Australia, the USA, France, etc. so everyone clearly knows delivery and milestone dates. More than happy with the solution that is being implemented. Thanks again for your support. It's helped me learn a lot.

[MichaIng]

I think with the year first it is pretty clear that the next number is the month and last the day. But with year last I agree that one can be nether sure whether the first or the second number is the month, so MMM is probably nicer then.

[Joulinar]

guys, did we ever tested this as non-root user? It seems it's working for root only.

https://dietpi.com/forum/t/dietpi-banner-no-certificate-found/16826

[MichaIng]

We didn't 🙈. The certificate, respectively the whole directory is probably readable for the root user only, I guess 🤔. Would make somehow sense as this is quite sensible data.

If this expectation is true, there is nothing we can or should do about it. Then it would be easiest to just skip the banner entry for non-root users and print a related info when it is enabled.

[gary2002]

Agree. We can’t go changing access privileges.Sent by iGaryOn 11 May 2023, at 06:24, MichaIng ***@***.***> wrote: We didn't 🙈. The certificate, respectively the whole directory is probably readable for the root user only, I guess 🤔. Would make somehow sense as this is quite sensible data. If this expectation is true, there is nothing we can or should do about it. Then it would be easiest to just skip the banner entry for non-root users and print a related info when it is enabled. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were assigned.Message ID: ***@***.***>

[MichaIng]

Since I use acme.sh, can you two verify that in your case /etc/letsencrypt/live/your.domain and/or /etc/letsencrypt/archive/your.domain (the first contains symlinks to the second) are not world-readable? I mean actually only the private key is sensitive while the certificate is public anyway, but probably just as an additional measure, the whole directory is non-executable other non-root users, so they cannot even see the content.

[Joulinar]

ping @JappeHallunken as I'm using NPM for proxy and certificates.