I’m using a rest service to fetch data. Twice in the last several months I got an exception javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching example.com found. when querying a service using Java/Tomcat. The problem seems to happen for several seconds and disappears on its own.
I updated my lets encrypt certificate few days ago and the problem happened for several seconds a day and a half after I restarted my tomcat/java with the new certificate. It also happened in the past after the renewal. Any idea what to look for? Do I have to do something with example.com after every reneal?
Thanks
I’m not sure I completely follow. You’re mentioning “a service”. But you’re neglecting to mention what kind of service this is: is this a service you are running? This service is using a Let’s Encrypt certificate? Or is it a service you’re connecting to?
Without a more complete understanding of what the setup is (unfortunately, my crystal ball has fallen on the floor yesterday, so I’m currently not a psychic) this is almost impossible to answer.
It’s a service I’m using and I have no control of. It’s a rest API.
The support of that service told me that they have changed nothing.
It happened twice. A short time after I updated the tomcat bundle file with the new certificates.
If you need more info, do let me know.
Thanks
What does your Tomcat have to do with this? Tomcat is a webserver, right? Or does it somehow connect to the API? Do you have some Java application running on Tomcat which connects to the API? Personally, I don’t have any experience with Tomcat, but I’ll repeat myself: we don’t have a crystal ball! I’m pretty sure you could have given us a lot more information than what you’re telling us in those five sencences. For example, which version of Tomcat are you using. What kind of application connects to the API. All of those details can be useful for other people of this forum. I’m signing off now, because I’m not a Tomcat user.
Apparently you understood much more than you think It is my tomcat server who is calling that other API. Letsencrypt renews its certs and create new PEM files. Out of those PEM files, I create a bundle.pfx file which tomcat uses.
It looks like a setting of some kind also needs renewal, something with the " No subject alternative DNS name matching example.com found".
Maybe each renew, this settings clear and I need to somehow refresh it… I don’t know, thus my question.
But in that case your Tomcat is acting like a client.. Where are those Let's Encrypt files used? And why? What's their purpose in bundle.pfx? I.e., what service uses bundle.pfx and in what way?
My tomcat is the client, I think the problem is with the 3rd party but I need “proof” because they say they did nothing related to ssl. Also the fact that the problem disappears on its own, gives me nothing to work with. I’m happy about it but my guess is that it will happen again in 2-3 months when letsencrypt will renew the certs again, just like it happened last time. Unless the timing is a weird coincidence.
I don’t know whose fault is it, I just looking for a way to solve it. I was hoping the error I receive will give a hint to people who understand about all this more than me.
I use virtualmin that every 2 months renews my certs automatically, I don’t even know how but it works.
It creates new PEM files inside my domain folder inside letsencrypt folder. After that, I create a bundle.pfx file out of the 3 PEM files. When I setup tomcat (few months ago), I set it to use this pfx file. Every time I create a new bundle.pfx file. I restart tomcat and all is good. Except for the above exception which I don’t know if relevant, it’s just the timing that made me write here my question.
My tomcat is actually a “client” that queries another server for information using rest. Twice so far, in the last 6 months (there were 2 renewals in this period) I got the above exception which fixed itself. Meaning the exception appeared for several queries and then disappeared.
Can someone explain/know the meaning of the exception?
The domain name it said, is it on the list of the subject alternative names of the certificate?
Yes, the domain.
It should be on my certificate? their certificate?
I did run sslopen command on my certificate and there I saw only my domain in list of the subject alternative names of the certificate. That makes sense, I think.
So if I understand well, your domain is not the example.com which is in the error message. The server side may expect a predefined client certificate. Is there any vague relation between your domain and that specific example.com domain?
Your Java/Tomcat application is contacting a service under the name example.com. The certificate provided by this service does not contain that domain name in the subject alternate name list, I guess. Check their certificate.
There may a be logging limit for the same error message. If you just restart your Java/Tomcat application (without doing anything with your own certificate), does the error message come back for a while?
I don’t have access to their server/settings and they say they changed nothing, I can’t “force” them to check anything on their side, moreover, they say I’m the only one with this problem… go figure. It could be that someone changed something behind the scenes and the support doesn’t know that. It could be that others receive this error for few seconds but ignore that because later everything works. I don’t know.
The error disappears, not just the logging, meaning I receive the expected result from their APIs instead of that error.
So if I understand correctly, the error means that the certificate of domain X does not have the domain X in its “listings”?
