Problem/challenge description: I have an java application, lets call it ABC, running on an Apache Tomcat web server (running on Linux). This ABC application communicates with a 3rd party website EFG (this website is not mine, i.e. I can not maintain it) using HTTPS. My ABC application is configured to use SSL/TLS so it needs the public key (the EFG's certificate) in the java keystore (cacerts file). So far I can manually download the certificate with the openssl command and import it in the cacerts keystore file.
Question: can I use Certbot tool to renew the EFG's certificate in my ABC application keystore file?
Based on my limited understanding, the Certbot tool is rather meant for the owner of the EFG website, am I correct?
Welcome. Yes, you can only get a cert for a domain name you control.
You are willing create your own cert for that site so it sounds like you do not care what their cert looks like. So, could you just not validate their cert in your ABC app? With curl you would do curl -k
I don't understand this part. Why would your cacerts file need to contain the end leaf certificate of the site? Usually key stores/cacerts files only contain trusted anchors like root certificates and not the end leaf certificate.
That's a GREAT way to have ABSOLUTELY NO SECURITY in your application at all. Hellooooooooo Man in the Middle-attack!
That was a suggested possible solution, but OP already understands that's totally not possible, as OP is not the owner of the 3rd party hostname EFG.
I have absolutely no idea how you've interpreted OPs post to conclude this. OP specifically says EFG is a third party website. So all the more reason to require a valid certificate.
@Osiris I am well aware what it means to bypass cert checks.
The OP wanted to create certs for a 3rd party site even knowing he is not the owner. Which says to me that he did not care what the 3rd party certs said. I was addressing his request as I saw it. I explained my reasoning which OP can discard or accept. Reasonable people may differ and all that.
You are of course free to express your opinion. There is no need to denigrate me when you do so.
To me, it says OP doesn't really understand how the PKI infrastructure works. To me, it says OP just wanted a "valid certificate", not knowing about the details of valid certificates to begin with. To me, it does not say OP doesn't care about security.
I don't want to denigrate you in any way and I apologise if my post came across as such, but I just think, if there's room for interpretation, it's a very bad idea to suggest bypassing certificate validation as a possible solution. If OP doesn't really understand what that entails and just thinks "Hm, if it works I'll take it!" without knowing this would be a very major security issue, that's very bad.
So my point and perhaps suggestion is: if you're not absolutely sure if someone knows the possible risks, it's probably a good idea to first ask that person to clearify the situation before suggesting possible very major security risks.
Personally I think your suggestion is such a major security risk I'm even considering editing your post... You don't want people finding this thread through a search engine without the knowledge of the possible consequences just implementing the suggestion, because they don't know any better.
While there are frequently many ways to interpret situations, we do need to exercise a reasonable degree of caution as some of the most vulnerable in terms of security do peruse our past discussions and suggestions here. For example, there are certain things that CAN be done to certbot's data directories that SHOULDN'T be done by the average user/operator/technician (which I'm fairly certain @MikeMcQ is well above by my observations), so I state the following in a very cliche way:
@griffin I edited my comment to remove the php sample – since you asked nice It did not help OP anyway as they are Java. It was just food for thought. I also did it as I now feel it was a bit of 'bad form'. (*1)
That said, I do not agree my post is problematic. I said if they were not concerned with the certs they could avoid checking them. That is a straight-forward comment. Whether they are concerned about the certs or not is still unknown. Whether they should be concerned is just one element of their overall app security strategy which goes well beyond the scope of the comments here. I offered it expecting them to assess the usefulness within their overall strategy - as any good developer should.
It is hard for me to be concerned about a theoretical future stranger mis-using this particular bit of knowledge. This is an oft-discussed topic online and off. I was not divulging secrets of a black box. I was quoting a publicly available manual.
(*1) After all, this is an LE site which promotes and issues certs. I recall the time I sent some product to UPS using FedEx delivery - bad form
You would be surprised at the ways in which some of our more wayward visitors (mis)use knowledge, my friend. There are certain parameters for certbot that I hesitate to even post without putting warning tape around their mention.
The longer you're here, the more... curious... things you'll see...
@griffin Oh, I did not say I could not imagine mis-use - just hard to be concerned about this item !
More seriously, someone incapable of evaluating this simple topic will not be able to do good security design. I can bear only so much limit to the spread of knowledge to protect them from themselves. Frankly, I fear just as much that these same folks will think once they have certs their security work is done - eek!
Sorry for my ignorance, I know very little about the whole PKI area.
"I don't understand this part. Why would your cacerts file need to contain the end leaf certificate of the site? Usually key stores/cacerts files only contain trusted anchors like root certificates and not the end leaf certificate." - good question, however I do not know the answer, since I did not develop the ABC application by myself (I am supposed just to administer it, in this case to find out, if automatic certificate renewal is possible).
The Tomcat does not have even SSL/TLS enabled in its server.xml file, the Tomcat just uses Java, that contains the cacerts keystore file, my guess is that the ABC application has some java dependency linked to the keystore cacerts.
Could you please confirm or refute, that the Certbot is just for the owners of Websites hosted e.g. on Tomcat?
That's correct, in principle. Certbot is an ACME client and the ACME protocol is for Certificate Authorities (CA) to issue certificates. And for a public CA to issue a certificate, it needs proof of ownership for the hostname for which a certificate is to be issued. So, indeed, just the owners of Websites.
It would not make much sense if anybody could issue publically trusted certificates for any site: the whole idea behind the PKI infrastructure is that only the site owner can get a publically trusted certificate for their site and not anyone else. What good would TLS be if that would not be the case?
Thanks for your answer, I get the basic concept of CA.
Maybe I was not clear enough. When the 3rd party website EFG for whatever reason changes their certificate (e.g. expiration), my application ABC stops working properly, i.e. I need to get the new certificate from the EFG website and import it into my cacerts keystore (I do not want the CA to issue the new certificate for my company, I understand that the CA will only do it for the website's owner), and I was looking for a way to automate this process, so maybe better question would be: can the Certbot help me with that or do I have to either do it manually or with some simple script?
We're trying to tell you that this approach is fundamentally flawed: PKI exists so that exactly this process is not required. You should import their (root) CA certificate instead - this way it doesn't matter if and when EFG renews their (leaf) certificate.