curl -i http://demo.topa.webgestio.com.br/
HTTP/1.1 503 Service Unavailable
Date: Thu, 26 Sep 2024 20:55:02 GMT
Server: Apache
Content-Length: 299
Connection: close
Content-Type: text/html; charset=iso-8859-1
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
something very strange is that, I removed the certificate from the other environment (from the other url = bacana.etpi.com.br) and redid it again and it worked, there was no error, but in this new url demo.topa.webgestio.com.br it doesn't work.
[image]
Both your domains are working the same now. Getting a "403" for your "home" page is unusual but there is a fresh certificate for each of the domains.
See this SSL checker site: https://decoder.link/sslchecker/demo.topa.webgestio.com.br/443
curl -i https://demo.topa.webgestio.com.br
HTTP/1.1 403 Forbidden
Date: Thu, 26 Sep 2024 21:35:11 GMT
Server: Apache
curl -i https://bacana.etpi.com.br
HTTP/1.1 403 Forbidden
Date: Thu, 26 Sep 2024 21:35:17 GMT
Server: Apache
I was just sending you this, lol
at the same time I was going to show you. lol
curl -i https://demo.topa.webgestio.com.br/
HTTP/1.1 403 Forbidden
Date: Thu, 26 Sep 2024 21:34:58 GMT
Server: Apache
Content-Length: 199
Content-Type: text/html; charset=iso-8859-1
You don't have permission to access this resource.
The demo domain gives a nice "200" for HTTPS now so that is good. I guess you will fix the other domain too.
Would you describe what the real problem was? There were many things talked about in the thread. I am just curious. Thanks
Of course I will explain how to solve it (with your help of course. lol)
I had a virtual host configuration called JkMount / demotopa* that was influencing the lets configuration. I commented out JkMount and ran it and it worked. After it worked, I added it (I removed the JK comment) and it worked.
#JkMount /* demotopa
#ProxyPreserveHost on
#RequestHeader set X-Forwarded-Proto https
#RequestHeader set X-Forwarded-Port 443
#ProxyPass / "ws://127.0.0.46:8000/" retry=5
#ProxyPassReverse / "ws://127.0.0.46:8000/" retry=5
Thank you all!!!
Perhaps certbot gets confused when it encounters "/*"
[in some coding languages... doesn't that signify the start of a comment?]
Maybe but jkmount is to send requests to Tomcat handler. So, if that supercedes what --apache plugin inserted the acme challenge would fail. This is probably the original problem.
You should not need the jkmount in port 80 anyway just in port 443 VHost.
And, now that it is back in place the cert renewal will likely fail.
Probably should not use --apache plugin with Tomcat anyway. Use --webroot instead.
Good observation! Since I returned with "JkMount /* demotopa", when I renew it, it will give an error. The strangest thing is that other environments I have are already ready and use "JkMount /* demotopa" and do not give this type of error.
I will change it and put it in the virtualhost *.443 and run it to check if it will give an error, but these configurations are working and have been like this for more than 8 years lol
But is running --webroot as simple as using --apache? Just so you know, I've never run --webroot, would it be possible to change the configuration or something like that? Sorry for my ignorance lol
In the HTTP server block?
Using which authenticator?
[using webroot would not care about JkMount]
Well, it would in the sense that JkMount would dictate to Apache where to find files. So, the Certbot --webroot-path would have to match where that is. It replaces DocumentRoot essentially.
I am pretty sure they could leave JkMount out of the port 80 block entirely and just specify DocumentRoot to match the --webroot-path. I don't have Tomcat to test with but I presume DocumentRoot would work fine by itself.
Another option if they really want JkMount is to use JkUnMount for the acme challenge folder. I don't know Tomcat very well so I suggest this only from their docs. And, it seems unnecessarily complicated compared to just using DocumentRoot.
Generally I think it is bad idea to use --apache plugin for Tomcat. The --apache plugin is not tested with any Tomcat extensions in the Apache config file so results unreliable.
They could even consider just using Apache as a standard reverse proxy to their Tomcat system and not use JkMount at all (anywhere).
Actually, you are right. The jk has to be in virtualhost *.443.
I saw that it was wrong, it should be in virtualhost *.443 and NOT in virtualhost *.80
My lack of attention.
I ran a new certificate for a new url (virtualhost) and it worked.
Do you even need jkmount at all? In the VirtualHost you showed above you proxy all requests to your 127.0.0.46:8000 service. So, there would not be any file requests handled by Apache anyway. Right?
Yes, I do, because if I create several URLs on the same server, I will need to create others. If I want to do this for several URLs, is there another way to do this?
I create a reverse proxy for Java using the AJP protocol.
HTTP --> AJP --> springboot app
It is just a layer to protect the application and have several applications using the same server address and port 443 HTTPS.
I don't know your app / server design well enough to say. Was just suggesting something given what I saw. We are getting a bit off-topic. Seems you know what you need to do to get and use Let's Encrypt certs so that is our main concern here.
True, one topic ends up leading to another. lol This is a conversation for a good chat. lol
I would like to ask a question. Can you tell me if it is possible to create a file with my URLs to create the certificate and then renew it, all in a *.sh file?
I think I am getting off topic.
I think I can close the topic now.
Sure, a cert question ... back on point 
First, you don't get a cert for a "URL". You get a cert for a domain name(s).
The way Certbot works best is to get your cert with one command and then renew it with an automatically scheduled "renew" command. I'll explain ...
To get a cert you use any of the Certbot methods, --nginx, --apache, --webroot, --standalone, or a DNS plugin. There is also --manual but that cannot be easily automated so ignore this.
So, something like these are run once:
sudo certbot certonly --webroot -w (DocumentRoot) -d example.com -d www.example.com
or
sudo certbot --apache -d example.com -d www.example.com
When that is successful Certbot gets the cert and makes a renewal profile in the /etc/letsencrypt/renewal folder for that cert.
Then a simple
sudo certbot renew
renews the cert using the same method you got previously. In fact, it renews All the certs that it has profiles for. A "renew" command is usually scheduled to run as a cronjob or systemd timer when you installed Certbot. Which one depends on how you installed Certbot and your distro (see here).
ok, thanks a lot for your help.
I'll do it.
I'll close the topic as resolved.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.