Are IP Addresses associated to certificates?

This isn't a help request more of a query.

certbot 1.22.0
Command used: sudo certbot certonly --manual --preferred-challenges dns

I've created a certificate that works fine. I've added this to a local apache2 web server and it's working as expected.

On the same server is a phone system that uses IP phones. When a phone provisions it works fine, but the certificate that is shown in the phone has a different IP Address to the server I've added my new certificate to.

My server is, the certificate that appears in the phone is
If I remove the Lets Encrypt certificate from the server, the phone will provision and doesn't contain the certificate. So I can only assume it's this certificate.

Pinging the FQDN that the certificate is using, returns the correct 1.20 address.

Any ideas ?


translating domain name to is dns's job and certificate doesn't care


Thanks, that is what I thought.
My local DNS does resolve this to 1.20 - not 1.122

LE issued certificates do not contain IPs.
Please show the certificate used.


DNS is resolving the FQDN to the correct IP Address.

So I've no idea why this phone is showing the wrong address when it provisions and the certificate is applied.

On the phone?
Which DNS servers do the phones use?


To answer your topic question:

Are IP Addresses associated to certificates?

Indirectly, yes.
[most] Certificates have only names.
But names can be resolved to IP addresses [usually by using DNS].

In the other direction...
If you connect to an IP, on a specific port, that system may provide a cert for that connection.
It might be the default cert, if no cert is found to match the requested name [IP].

But, in general, no; IP addresses are NOT directly associated with certificates.


Can you provide more detail on that?


Thanks for the replies.
When the phone provisions from the server, it's list of trusted certificates are updated.

With the Lets Encrypt cert is applied to the server, this results in a new certificate appearing in the phone with the IP associated with it.

This isn't the IP of the server and isn't what the FQDN resolves to internally.

The phone is using a local DNS server. From the phone I can ping the FQDN and it is resolved back to the correct IP Address.

I'm at a loss as to why it's showing the wrong IP.


1 Like

Do you control the DNS?
If so, what name(s) can return the IP

Please detail this part more for me - take a picture (if needed):


Locally we run opnSense with Unbound DNS.
This only has one override which is the FQDN pointing to 1.20
Hosted DNS has nothing relating to 1.122

The phone simply shows:
Issued To:
Issued By:
Expiration: Oct 13 13:20:41 2033 GMT

I've no way of inspecting that further. I'm going to run a pcap while it provisions and see if that shows anything.



The issuance details suggest that it is a self-signed certificate that was not created by the Let's Encrypt CA. Let's Encrypt can only issue certificates for DNS names. Your question is probably better directed to your VOIP platform.


Please show the leaf cert of that server certificate.

I agree with @linkp, the phone is using a self-signed cert.
That may mean that it can't register properly with the server.
I suspect that the phone is too old for the cert type/ciphers being used by the server now.


There is something going on with the server, I don't this it's the phone or Let's Encrypt.
I'm doing a backup and reverting to an older snapshot to see what that shows.


1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.