How to use IP address as common name in selfsigned certificate? - ssl

I recently generated self signed certificate using OpenSSL with common name as 'localhost' it works fine.
I tried using IP address instead of localhost, which Chrome browser rejected saying ERR_CERT_COMMON_NAME_INVALID, because IP address is not resolved to common name.
How can I fix it?

Related

Can a valid SSL Certificate cause a Certificate Error if the DNS name used in the CSR is pending association with the machine it is to be used?

Currently in the process of moving an existing public facing site from Azure to our internal network. In order to retain the validity of the SSL (https) protocol I had to request another certificate for the the machine where the new site will reside.
I installed the cert on the system and it says it installed successfully but the site is showing a Certificate error in IE.
So I'm wondering if the fact that the CSR was created using the DNS name and the DNS hasn't yet been redirected to the new location; is the reason the Cert Error is being displayed?
The only way to access the new server is via IP address externally, not by the DNS name.
Does the site certificate get bound during creation to the DNS name of the server where it is supposed to reside or by the encrypted signature of the actual machine when the CSR (Certificate Signing Request) is generated?
Or is it both?
The only way to access the new server is via IP address externally, not by the DNS name.
I'm not fully sure what you are asking. But my interpretation of the question is that you have created a certificate for some DNS name (i.e. example.com) but then try to access the site by IP address since the DNS name is not available yet. And then you wonder why the browser complains (with an error you unfortunately not include in your question).
If my interpretation is correct then the reason for the browser error is that the hostname in the URL (i.e. the IP address you used) does not match the subject(s) of the certificate, i.e. the DNS name. This validation of name in URL against subject of certificate is an essential part of the certificate validation.

Self signed SSL certificate is not verified on local when i tried to access from computers own ip

My goal is to test my web applications ssl pages from another computer on the same network.
I receive an unverified certificate error. I've created a lot of different certificates to fix the error but it did not. Is there any suggestion?
Error in chrome:
NET::ERR_CERT_COMMON_NAME_INVALID
Error in Mozilla:
SSL_ERROR_BAD_CERT_DOMAIN
Not secured
Secured
Ensure in your certificate the IP address should be in a SAN (subject alternate name) entry of IP address type.

How can I fix Error code: SSL_ERROR_BAD_CERT_DOMAIN after installing certificate?

My web server's FQDN is foo.bar.com
It is aliased and most commonly accessed at baz.bar.com
I had a SSL certificate generated by our netsec guys and I installed it to the server and enabled the site. Now I am receiving Error code: SSL_ERROR_BAD_CERT_DOMAIN because the certificate is only for foo.bar.com, not baz.bar.com
How can I get this resolved?
The hostname in the URL you use to access a site must match a subject of the certificate. This means if you want to access the site as bot baz.bar.com and foo.bar.com you either need a certificate which contains both or need two certificates and serve the certificate based on the request name. In the last case the client must support SNI if both names point to the same IP address.

Set Up Of Common Name Of SSL Certificate To Protect Plesk Panel

A PCI Compliance scanner is balking that the self signed SSL certificate protecting secure access to Plesk Panel contains a name mismatch between the location of the Plesk Panel and the name on the certificate, namely the self-signed cert's name is "Parallels" and the domain to reach Plesk is 'ip address:8443'.
So I figured I would go ahead and get a free SSL certificate to try to fiddle with this error. But when I generated the certificate I used my server domain name as the site name when I generated the certificate. So if I visit 'domain name:8443' all is fine, no ssl warning. But if I visit 'ip address:8443' (which I believe is what the scanner does) I get the certificate name mismatch error, Digicert's ssl checker says that the certificate name should be the ip address.
Can I even generate a certificate whose common name is the ip address? I am tempted to say I should just do what the PCI scanner accepts, but what is really the correct common name to use? Anybody run into this issue before?
You can try a Subject Alternative Name extension for the IP address. Also, you can keep "Parallels" as the Common Name, and add a Subject Alternative Name extension for the DNS name, which should be the preferred match (i.e. higher precedence than Common Name.)
Can I even generate a certificate whose common name is the ip address?
No, you shouldn't. While this may work with some browser, this will fail with clients that are compliant with the HTTPS specification:
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
If you want to use an IP address in a certificate, you must have it in as a Subject Alternative Name (of type IP address, not DNS). You can check this question for details on how to do this.
However, more importantly, it sounds like in your case you don't need to use the IP address at all.
The purpose of certificate name verification is to check that the identity in the certificate matches the identity as requested by the client. (Reverse lookups or other names don't matter.)
The fact that you've already configured your system for your domain name and that it works when using the name means that it's already configured properly. It sounds like your giving your scanning tool the IP address of what you're trying to scan (which isn't what the clients would normally use): make it use your host name instead. That's what the scanning tool should try to compare anyway.
Can I even generate a certificate whose common name is the ip address?
(Thanks Bruno for pointing to right solution) There is enough to set subjectAltName in CSR.
IFAIK there is no such option in Plesk, but here good instruction for openssl http://apetec.com/support/GenerateSAN-CSR.htm

Changing ip address for a domain name - how to test if ssl will still work?

I've got a domain purchased from godaddy (example.com), as well as an ssl certificate from them for that same domain. I have a single machine running a web server and a static ip, the domain from godaddy points to that static ip. The ssl cert is installed on that machine, and everything works fine.
Now I need to start hosting from a different machine, which has a different static IP address. I believe all I have to do is change the IP address for my domain in godaddy's control panel, and the ssl certificate should still be valid, even though it's a new IP address.
Is there any way to test this beforehand? Is my assumption correct that just changing the IP address in the domain record is all I have to do?
Thanks
SSL certificates are (almost always) associated with domain names, not IP addresses. Assuming you have a standard configuration for your SSL cert, you're fine.
But! You want to test this beforehand. OK:
openssl x509 -in yourcert.crt -text -noout
This command will allow you to examine your certificate. In particular, look for your hostname. Mine says something like:
X509v3 Subject Alternative Name:
DNS:mail.cternus.net, DNS:cternus.net
If your hostname is in there (and your IP address is not), you're golden.