Thank you for the logs. I’m checking them, if anything catches my eye, I will let you know.
1 Like
Please additionally provide log of letsencrypt from /var/log/letsencrypt/letsencrypt.log inside the Community Server container
here’s the link: letsencrypt.log - Google Drive
I forgot to mention that, today, since we can’t get the https to work, we deleted the ssl via the control panel. which then after, we can’t access via https anymore. if we try without https (via http), it would still redirect to https and get an error that the site is unaccessible. so we accessed the site via http using the ip address instead. from there we re-created the certificate via the control panel. thenafter, this allowed us to access the site via https with errors again on expired certificates.
Unfortunately, in this log I cannot see any information about the renewal of the certificate.
Is there any other letsencrypt log with the date when the issue occurred?
I checked the other logs in the /var/log/letsencrypt folder and seems all log files have the same file size and content. 
the SSL certificate expired 4/21 but there are no logs that day that is different.
also, i just noticed just now that in the control panel, the generated domain is now a dash “-” and does not show the full domain name anymore. Seems this was after we deleted the SSL via control panel yesterday and recreated the sll.
I have another concern - let me know if I need to write this in another post, but this is related to this issue. The concern is this - if we delete the SSL via control panel, we expect that the https URL will not work anymore and will be inaccessible. However, after deleting the SSL via control panel, when we access the site via http://, the browser is always redirected to the https:// URL After deleting the SSL, the site cannot be access via http domain name as it will always redirect to https domain name. the site can still be accessed via http IP address though. How can we prevent forced redirection to https domain name after the ssl is deleted? thank you.
Hello @rodster
The dash instead of the full domain name may be the result of accessing portal via its IP instead of domain name and attempting to generate certificate. Which leads to your second concern - information about protocol is stored in browser local storage so it remembers how site was accessed. To avoid “redirection” you can either reset browser cache or access the portal via Incognito mode.
Right now, I’d recommend accessing the Control Panel via Incognito mode to remove current certificate, then access it again via domain name of the portal to generate new certificate.
hi @Constantine. I did what you said here; deleted the certificate. then use incognito mode to access the site via http domain name - it works now, no more auto redirection. then I clicked on “Generate and Apply” and then click “Apply”.
However, the resulting generated domain is still a dash:
and the certificate generated is still invalid:
to add, the letsencrypt.log is still the same no details regarding this failure.
Hello @rodster
Was Control Panel accessed via domain name during certificate generation?
Usually ‘dash’ appears when certificate is generated for IP address, i.e. no common name cannot be fetched. Please try generating once more in Incognito mode.
Also, provide versions of all components of the portal. In the Control Panel you can find them in Updates menu.
hi @Constantine Yes, control panel accessed via http domain name. We’ve done this several times - removed certificates and recreated but results are the same. the certificate is still invalid. Here are screenshots (below). also, here’s a screenshot of versions of all components.
v
Hello @rodster
There is no need to additionally press APPLY after generating certificate.
By pressing GENERATE AND APPLY it does it automatically.
I’m sorry for failing to mention it.
@Constantine, I tried that but it the site won’t be accessible via https. After clicking “Generate and Apply”, the site can only be accessible via http. I also tried delete, “Generate and Apply”, and reboot - the result is the same, the site can only be accessible via http and cannot be accessed via https
where can i find the logs for “Generate and Apply”? it says says that it’s successful, however the site is till inaccessible via https
@Constantine, I’m finally able to resolve this. Here’s the issue - the onlyoffice server is behind a nat firewall. for this type of installation, apparently both 443 and 80 inbound should be open at the point of certificate renewal. Seems that letsencrypt, for some reasons, probes port 80 of the site before renewing the certificate. we only enabled 443 as the site has been working on 443, and disabled the public IP’s port 80 inbound.
Here’s the odd part though:
- there is no error log file from community server, control panel, and even let’s encrypt that the “Generate and Apply” failed.
- the “Generate and Apply” even generated a success notification.
- no error was shown that port 80 was required
Glad that finally this is resolved. Thank you
Hello @rodster
Sorry for the delayed response.
I’m glad to hear that you’ve managed the whole situation out.
I will try to check out this behavior. If I get any details, then will provide them.
1 Like
Here are some more information about the need to have port 80 opened for inbound:
https://letsencrypt.org/docs/allow-port-80/
Also, there is a direct answer to the question “Is port 80 required for renewals?” in this thread:
https://community.letsencrypt.org/t/is-port-80-required-for-renewals/121432/4
Spoiler: it is.
thank you @Constantine. I didn’t know I had to open port 80 for the auto renewal to run successfully, until that was one of the variables I was changing, and was surprised that it worked. anyway, I hope this post helps others who may experience the same issue on certificate auto renewal. thanks again.
1 Like
It surely does.
Thank you for your patience.