Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
The simple solution is to check the current active cert. (You can easily use SSL Labs for that.)
A more in depth look would be to find the latest cert on the system and check the issued date. (Manual and technical - by nature.)
That assumption is not based on all the facts.
A "warning email" is only associated with the exact cert mentioned.
A site can generate several additional certs during the lifespan of the earliest unexpired cert - for various reasons. There is no way to know which cert(s) are being used and which are no longer in use. The warning message is simply to inform you so that you can look into the matter.
Your current site cert shows an expiration of 2018/12/12:
Great. Thanks. Looking at all the posts, you could get rid of all the newbie questions like mine with a newbie tool.
Write a simple command line tool that can run on Linux, Mac, or the Linux on Windows thing. It has a simple ini file. In the ini file you just enter the names of domains. Run the tool locally and it goes out and returns the detailed information the google tool returns.
80%+ of the simple questions go away.
If you want to get fancy, enable it to do some very simple, secure, and basic maintenance tasks.
Sure, it perpetuates stupidity but so do all the good cookbook solutions you offer. The problem will not go away.
People do not want:
to be linux sysadmins
to overpay for proprietary solutions like Squarespace or Ghost hosting
People want:
to be properly secure and private
to develop their business, content, hobby, job–the things they need to do, unlike the “do not want” list above
It’s not that people are stupid; it’s that they want to focus on where they are smart.
Let’s Encrypt is great; I donated. It’s a lot of work for you. Just consider this suggestion and, of course, put on your own thinking caps and reason about, “how can we get ahead of this and help more people, more easily, with less work, and more satisfaction all around?” You will definitely come up with something.
I’m confused…
Let’s say a “tool” did exist.
How would end-users even know it exists?
How would they “just use it” without still coming here first to get their questions answered?
Maybe sending them a link to an “online tool” in the expiration email could direct them to that “more automated” help…
But the questions that come here should, in time, find previous matching answer(s) - so this should not be a never ending task.
You search.
You find.
You apply.
You move on.
The first time someone came, you’d say—here is the link to this easy maintenance and setup tool.
There is also a Let’s Encrypt web site: that’s where you’d download it from.
You could also just do a tool that ran on the host machine, which is invariably Linux—so that simplifies things quite a bit. Ghost has a cmd line tool that must be run on the target host. It’s better than a script and can do some config auditing, but it does “break” pretty often in not being able to sort out a config—still it is more robust than a bash script by quite a lot. For query only a similar tool would could be local—a sort of narrow version of ansible to do only one thing. If there were a host side to the tool then there could be an api at the server maintenance tool that the “local” client could talk to.
It was only a suggestion to make things easier; perhaps that is simply not a goal. You must see the same questions over and over—much of the time. There will always be harder questions and variations of config that are not so standard—so there will always be demand for the forum. It’s clear you don’t want to do this. Esoteric knowledge preserves a Linux hacker’s sense of superiority. I don’t find that satisfying at all; some people inevitably do.
But really, the problem is that the warning email is misleading/being misinterpreted/is user-unfriendly, no?
So perhaps the actual solution is to amend the wording in the email to indicate that the “real expiry” can be checked by with a couple of clicks on the certificate details in-browser, along with a link to some screenshots on how to do that.
You don’t introduce more tools to fix a basic communication problem.
Sure: a link in the email solves this particular issue and it’s a common issue. And easy to do.
The tool doesn’t quite work. The MacOs compatibility line needed to be changed from: _date=gdate to: _date=date
It didn’t produce output that made sense compared to ssllabs or the google site. Something probably wrong with date parsing. Here is the output:
I have found 6 non expired certificates (3 final certs and 3 pre certs) (max number of certs searched: 100) for domain a-view.org and its subdomains *.a-view.org
CRT ID CERT TYPE
DOMAIN (CN)
VALID FROM VALID TO EXPIRES IN
812974912 Final cert
a-view.org
-17834 days
774560719 Final cert
a-view.org
-17834 days
766665836 Final cert
lnotes.a-view.org
-17834 days
743810197 Pre cert
a-view.org
-17834 days
703187621 Pre cert
a-view.org
-17834 days
674012320 Pre cert
lnotes.a-view.org
-17834 days
The broader suggestion was to cover some broader list: how do I renew? I changed my domain name… How do I delete my old unused certs? How do I verify automatic renewal? There are a handful of these that recur. And there is no way to do everything. It would be a nice start to just do a setup for a base domain, with some subdomains using a very standard config for perhaps the 3 most popular web servers. Then, if a person used this “standard” setup, the tool could do maintenance only for this restrictive case. Probably would cover a lot of folks who just want certs for blogs and websites built with very popular frameworks (OK—I am wandering into dangerous territory….). I think the frameworks might not matter—only the webserver.
Let’s Encrypt and certbot are great. Clearly the way to go for self-administered small sites (and maybe big commercial sites, too….?). It would be nice to really simplify even beyond what certbot does. But, that would be a non-trivial effort. EFF would really want to get behind that.
Let’s just drop it. I thought I made a friendly suggestion. The first response I got from one the community maintainers was pretty unfriendly and really unrepresentative of what a good job people here consistently do. I got a fast and useful response to my original question. That’s at least one question I won’t ask again. It’s really important in this era of hacking, security breaches, non-state criminality, and probably state actors also not always acting benignly that we make strong internet security/privacy widespread, easy to deploy, and reliable. Let’s Encrypt is really doing a great service to the larger goal. I donated to EFF in support of it. I am glad you are here.
