This isn't a help request more of a query.
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 192.168.1.20, the certificate that appears in the phone is 192.168.1.122.
If I remove the Lets Encrypt certificate from the server, the phone will provision and doesn't contain the 192.168.1.122 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?
[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 192.168.1.122 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.
Do you control the DNS?
If so, what name(s) can return the IP 192.168.1.122?
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: 192.168.1.122
Issued By: 192.168.1.122
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.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.