Hi,
I issued an SSL certificate with and FQN, hostname and IP in the Subject Alternative Name extension. It’s working okay if I either use the FQDN or the hostname in the browser to connect to the console, but I get this meesage:
Your connection is not private
Attackers might be trying to steal your information from NN.NN.NN.NN (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
So, the certificate doesn’t seem to be working if I use the IP to connect to the console, it only works if I use the FQDN or hostname.
Understood. Thanks.
Users from the inside can still attempt to log in using the server’s IP.
Is there a way to block access if they use an IP?
Users can still proceed and log in provided they have user & password, only that over an unsecure channel this time = (
This server could not prove that it is N.N.N.N ; its security certificate is from FQDN_HERE . This may be caused by a misconfiguration or an attacker intercepting your connection.
Proceed to N.N.N.N (unsafe)
For your problem it is more important how the CSR was created.
The error message says nothing about a SAN problem, but a invalid CN.
Also the SAN fields from the resulting certificate would be interessting.
I always thought, that its easier to fake internal ip addresses and not using the DNS name means, that there is an external reference (the dns server) that does not need additionally to be attacked.
But yes, there has to go a lot wrong to make that happen and after some digging I was not able to find any hints in the internet. So maybe I was just wrong
If you really want to have a certificate that is valid for an ip as url (which has some security implications) you will have to add the ip as dns san entry to the certificate. Most browsers do not accept ip san entrys anymore.
What security problems do you see here?
An IP inside the SAN is perfectly fine and used in environments where is no DNS service available but certificates are needed.
CA/B Forum, an SSL industry regulator, sets the following requirements of using IP addresses in SSL certificates:
If the X.509 v.3 certificate contains an IP address, then it must be included in the SAN extension as the iPAddress name (not dNSName).
A certificate may include multiple IP addresses
There are some problems with handling iPAddress in the SAN in Windows® prior to version 10. To cope with these issues, you must add an IP address to the outdated commonName field of the X.509 v.3 certificate. If the certificate contains an IP address in the SAN extension with iPAddress and in commonName, then the certificate check will succeed. It is worth noting that downside of this implementation is inability to include multiple IP addresses in the common name of single certificate.
TY so much. I will test this in a while, but you have a very valid point there.
I had included the IP, FQDN and hostname in the cert’s SAN all along. But the error message clearly states invalid CN. I will put in the IP as CN value in the CSR, I guess this will fix the error.
BTW, no errors when I put either the FQDN or the hostname in the browser to reach to Check_MK console, only when I use the IP. I was confused I got an error because I had the IP as DNS entry in the SAN already.
I will report back once tested.
Edgar Zapata
Inside the CN you have to use a valid FQDN.
The IP is only fine if used as SAN.
That was also said in the posted article.
But as @Anders said, if you have the possibility to use the FQDN to access the service than you should do it this way. I only need IPs inside SAN for environments without DNS, but with working certificate validation.
Users can still reach the console using the IP, the thing is the certificate is not valid so I get “Your connection is not private” Warning message. So a secure connection can’t be established by simply using the IP instead of the FQDN in the browser.
For what it’s worth, we finally managed to protect access to the console when using the IP in the URL by adding an IP-Address additional entry type as part of the SAN rather than a DNS-Name entry type.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
