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 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.
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.
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.
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.