Server certificate doesn’t include an ID which matches server name
When attempting to configure SSL on a server designed to run Apache or potentially another similar web hosting technology, you might end up getting an error that tells you that the server certificate does NOT include an ID which matches the server name. This is technically just a warning and you could theoretically work your way around it.
It’s a much better idea to do a little troubleshooting in order to get things working again like normal. Once you have the server name and certificate matched up, you shouldn’t have to redo any of these steps the next time that you update the system. You may need to regenerate a few things if a simple file edit doesn’t fix things, but once you’ve done so you won’t have to configure files any further.
Method 1: Editing the httpd[dot]conf File
Start by having a look through the 
file, which might instead be at a slightly different place if you’re running Apache on Fedora, Red Hat or CentOS. Debian and Ubuntu servers should have it located at this first address. Look for text that spells out the server certificate does NOT include an ID which matches the server name warning message.
You might find that it’s throwing out 443 or another number after each part of the IP address but no other SSL problems. In this case, you might not have told Apache on what ports to listen to. Run
and find a line that reads Listen 80. Underneath it, add Listen 443 or whatever other port number you might need. Once you’ve saved and closed the file, you can use 
to restart the httpd process.
Those running Ubuntu or Debian servers might not have this file or they may find it’s completely empty, unlike those using some versions of Fedora or Red Hat Enterprise Linux. In that case, use
to edit the text file needed to add ports to listen to.
In many cases, this should have corrected the problem. If not, then check all the relevant networking issues before proceeding to inspect the certificate situation.
Method 2: Regenerating New Certificates
These warning messages could also come up if you’ve been working with expired certificates that you signed yourself. Should you need to regenerate them, try using
and look for two lines marked File and KeyFile. These will tell you where the location of the certificate key file is when creating an SSL certificate.
If you’re working with a professional signatory firm that provides official World Wide Web certificates, then you should follow the specific instructions provided by your licensing organization. Otherwise, you’ll need to sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout KeyFile -out File, replacing KeyFile and File with the text that you were able to get out of the previous cat command. You should have found the location of two different files, which serve at the input and output for the certificates.
Assuming that they were out of date, simply doing this should be enough to fix the error, but you may have to restart the service before it stops throwing warnings out at you.
You can also find out a bit more about the certificates that you currently have installed to aid you in the troubleshooting process. To see what name is currently on your certificate to ensure it matches, you can run openssl s_client -showcerts -connect ${HOSTNAME}:443, though you’ll need to put your actual hostname between the brackets. Replace the 443 numeral if you’re having problems with a different port.
On the off chance that you have multiple certificates installed on the same device and served from the same IP address, then you’ll need to run openssl s_client -showcerts -connect ${IP}:443 -servername ${HOSTNAME}, replacing IP with your actual IP and filling in the hostname. Once again, you may have to replace 443 with a different numeral to match your specific use case.
Keep in mind that you have to ensure that the correct hostname gets specified as an alias or the common name when the CSR got created in the first place.
