That's interesting...
I found that IP block listed on 2020-03-17.
You might want to scan your system(s) for malware.
2 Likes
Did you try finding the error page with the grep commands I showed?
The text of that page has to come from somewhere. It is not an automatic part of nginx.
Could there be some kind of firewall or other service that is blocking inbound requests to that server? I saw on the TransTelCo site they offer cybersecurity and content filtering - could they be blocking requests? I do not know why they would block with a 404 error but maybe your company configured it that way.
Are there any other kinds of requests to that server that are not working right? That is, other than the Let's Encrypt requests and my test attempts.
2 Likes
I don't know how but I just tried to renew it again with certbot renew and it worked, right now I can't restart the server because they are using it but it indicated this to me:
telsur-lb:~ # certbot renew
/usr/lib/python2.7/site-packages/OpenSSL/crypto.py:12: CryptographyDeprecationWarn ing: Python 2 is no longer supported by the Python core team. Support for it is no w deprecated in cryptography, and will be removed in the next release.
from cryptography import x509
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/viciremote.telsurcallcenter.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for viciremote.telsurcallcenter.com
Using the webroot path /srv/www/htdocs for all unmatched domains.
Waiting for verification...
Cleaning up challenges
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/viciremote.telsurcallcenter.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/viciremote.telsurcallcenter.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
We both hope this does it 
!
You do not need to restart nginx to refresh the certs, you just need to reload it which should not disrupt ongoing activities.
service nginx reload
2 Likes
I just validated and the active certificate appears 
Thank you very much for all the help
1 Like
Excellent. I wish we knew why it started working but glad it is.
You still should make the changes @griffin described earlier. This was to:
Change this:
ssl_certificate /etc/certbot/live/viciremote.telsurcallcenter.com/cert.pem;
to this:
ssl_certificate /etc/certbot/live/viciremote.telsurcallcenter.com/fullchain.pem;
Note: it is just the file cert.pem to fullchain.pem
Then, another nginx "reload" like earlier
Right now your website might show an invalid cert message depending on browser and version used. See this site that shows your "leaf" cert is now fresh but there are no "intermediates". This change will fix that.
https://decoder.link/sslchecker/viciremote.telsurcallcenter.com/443
2 Likes
Ok, this change where should I make it? 
I last saw it in this file:
/etc/nginx/conf.d/load-balancer.conf:
Look for the line that has cert.pem and change that to use fullchain.pem. Leave the path and all the rest the same.
It will be in the "server" definition for viciremote.telsurcallcenter.com
If you are worried then do not do it. It was wrong before you took it over. But, it might avoid strange problems in the future.
2 Likes
ok, currently it is like this:
server {
listen 443 ssl;
server_name viciremote.telsurcallcenter.com;
ssl on;
ssl_certificate /etc/certbot/live/viciremote.telsurcallcenter.com/cert.pem;
ssl_certificate_key /etc/certbot/live/viciremote.telsurcallcenter.com/privkey.pem;
ssl_trusted_certificate /etc/certbot/live/viciremote.telsurcallcenter.com/fullchain.pem;
location / {
proxy_pass https://backendssl;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
it should look like this:
server {
listen 443 ssl;
server_name viciremote.telsurcallcenter.com;
ssl on;
ssl_certificate /etc/certbot/live/viciremote.telsurcallcenter.com/fullchain.pem;
ssl_certificate_key /etc/certbot/live/viciremote.telsurcallcenter.com/privkey.pem;
ssl_trusted_certificate /etc/certbot/live/viciremote.telsurcallcenter.com/fullchain.pem;
location / {
proxy_pass https://backendssl;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Right? It is also the same but with listen 446 ssl, does it change there too?
This line is not needed:
If you can't work without it... use:
ssl_trusted_certificate /etc/certbot/live/viciremote.telsurcallcenter.com/chain.pem;
3 Likes
Yes, the 443 change is as you show.
I never saw how you used port 446 server but should be ok for that too.
3 Likes
Thanks, I already removed it
1 Like
Ok, thank you very much, I saw that now everything appears OK
It's all good. We have not detected any issues.
https://decoder.link/sslchecker/viciremote.telsurcallcenter.com/443
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.