I configured SSL on IIS 7 for my ASP.NET website. But its giving error that Server certificate does not match the URL, even after providing the same name "localhost" in certificate friendly name as that of my server.
I also changed the name of the server as ASP-DELL i.e. the name of my computer and created a certificate with that name and started the website as http://ASP-DELL/HC/index.aspx but it still showing this in Google Chrome:
Please help!
What's missing (or at least unclear) in your question is what the common name (not friendly name) of the certificate you installed/purchased/configured....
Certificates are issued to a specific common name/host name, and the url must match it specifically.
Until SANs (subject alternative name) became common, I recall the days when one had to purchase 2 certificates for the "www" web site and the "site without the www". These days there are also "wildcard certificates".
Its also unclear what type of certificate you are referring to, self-signed/test or is it something you purchased? I wouldn't think a certificate provider will let you purchase a certificate with a common name of "localhost" (but then again I could be wrong).
In production, certificate common name will equate to your DNS fully qualified url -e.g:
DNS: www.google.com
Certificate common name: www.google.com
if the certificate includes a SAN, then default would likely be: google.com
this means the certiifcate will work with or without "www" (otherwise it would only work specifically for www.google.com)
I think by adding domain of your network with your computer name could help to fix it as I remember I went through similar situation.
can you change it from
http://ASP-DELL/HC/index.aspx
To
http://ASP-DELL.YourNetworkDomain/HC/index.aspx
Related
Can someone answer a simple SSL Cert question for me to derisk my decision?
My Stack: Bitami WordPress instance on GCP VM.
Situation
I have a website with an SSL cert linked to my domain name.
I started an instance with a new static IP address.
I remapped the domain name to the new servers and added the correct credentials [confirmed everything is configured correctly with the GCP team].
Ran -dig command and confirmed new instance is mapped to the domain name.
Problem
The domain name will not load in the browser. Get the "NET:: ERR_CERT_INVALID" message.
My Diagnosis
I haven't transferred my SSL to my new IP address.
Confusion
Everywhere I read says the SSL is mapped to the domain name, not the IP address itself. So theoretically there should not be an issue.
Question(s) to you
Do I solve this simply by generating new SSL cert on the new instance? Will that just overwrite the old SSL cert and map my domain name to the new SSL cert?
If not - what's the solution?
I don't understand the technical relationship between IP address, domain names, and certs. I have read as much as I can and everyone seems to talk around it but not explain it in detail.
Thanks in advance!
Bitnami Engineer here,
If you created a new instance from scratch, you will need to migrate the SSL certificates from the first instance to the second one. You can either copy the SSL certificates from the machine or download them again from the CA website and substitute the files you have in the /opt/bitnami/apache2/conf folder.
In case you were using a Let's Encrypt certificate, you can generate new certificates by using the Bitnami HTTPS configuration tool (/opt/bitnami/bncert-tool) or by running the CLI tool to generate new certificates. If you use the Bitnami HTTPS configuration tool, you won't need to modify the Apache's configuration, the tool will do that for you. You can learn more about it here
https://docs.bitnami.com/google/how-to/understand-bncert/
Please remember to confirm that the domain name is configured properly by checking your domain using this online tool before trying to generate the certificates
https://www.whatsmydns.net/
New problem.
I used the bncert tool as per Jotas recommendation and it worked well.
I checked my domain name via 'whatsmydns' as well as my SSL via an SSL checking tool. All worked out as expected - my IP address is matching against my Domain name and SSL is matching against my domain name.
I type my domain name into the browser and it loads my site with the padlock, across all browsers.
So from the outside - it looks like everything is fine.
But I have two issues still.
Problem #1:
In my WordPress 'general>settings', I tried to update my 'WordPress address' and 'site address' but they are greyed out. So I updated my wp-config file with the new https addresses as per these instructions which have worked for me before without issues (https://www.wpbeginner.com/wp-tutorials/how-to-change-your-wordpress-site-urls-step-by-step/). It didn't break the site, but I could no longer log in. As soon as I deleted the new wp-config code, I could log in again. So if that won't work, I now have no course of action to update my 'WordPress' and 'site' addresses.
So my questions are - do you know why this won't work? Is it a bitnami quirk? And does it matter? If the domain is working, does it matter if I keep the wp-config file as an http address and not an https address?
Problem #2:
My domain name takes me to my site at the correct IP address. It loads with a secure padlock icon. I can log in. Everything works as it should.
If I use the IP address, however, instead of the domain name, it also loads the same site but as an insecure site with no padlock.
Question - Any idea how that is possible? I thought a domain name was just a human-friendly version of an IP address. And if the webserver is a single server, how can using a domain name versus an IP address generate different front end results?
Thanks again team, as a person who is new to this community, it really does give you faith in humanity.
I have deployed an OpenVPN server from GCP market Place and have attached a Domain name to it along with the SSL certificate. Currently, I am able to access the server through both
https://domain-name.com
https://x.x.x.x -(Server Static Ip)
I want the server to be accessible only through the hostname and not its Server IP as the latter URL gives an SSL security error as the SSL certificate is attached to the Domain name and not to the server IP.
Can anyone help me to restrict it or give some advice to solve it?
You could try to do it(prevent access by IP) but I advice you to not try to do it.
Theoretically it could be possible for your HTTP server to reset SSL connection when browser sends "wrong" SNI(Server Name Indication) in a handshake.
Thus you could prevent your browser displaying security alerts.
Instead your browser would show network error message.
I doubt you would like to trade one type of error to another one.
I suggest you to do nothing about such "error" because legitimate visitors will come to your site via domain name and will not see such security warning.
Also there is huge possibility that legitimate visitor (with paranoid mindset) will use browser with SNI feature disabled so your server will not be able to make difference between good and bad URLs.
PS: here are relevant questions and discussions at reddit and at ServerFault and another one
We have used wild card subdomain to our web app running iis.it is working fine.Now we purchases ssl and implemented , it is working for https://www.xyz.domain.com or https://www.domain.com but did not work on https://domain.com.
Please help|||||
I assume your SSL certificate was issued for www.domain.com. Typically, when you purchase an SSL certificate that is "wild card", the CA puts two DNS names in the subject alternative name of the certificate. For you, it is probably www.domain.com and *.www.domain.com. It is unlikely that the certificate is issued for domain.com because it would not be valid for www.xyz.domain.com since wildcards only go one sub domain deep.
You need to work with your CA on getting the right kind of certificate. You need a certificate that is valid for domain.com, www.domain.com, and *.www.domain.com. There is nothing you can do to work around this other than get a new certificate with the correct SAN.
I've read a bit about SSL certificates, and in particular I've read that an SSL certificate "requires a dedicated IP address". Now, I'm unsure of the meaning of this; does it mean that the certificate requires a dedicated IP address separate from the IP address used for normal HTTP communication, or just that it can't share the IP address with other SSL certificates?
To clarify, I have a VPS with a dedicated IP address. The VPS is hosting quite a few different sites, including several subdomains of the main site, but only the main site and the subdomains requires SSL. Can I simply purchase an SSL certificate for *.example.com using my current IP address, or do I need to get one that is separate from the other sites on the VPS? Or even worse, do I need to get one that is separate from all HTTP traffic on the server? Keep in mind that none of the other sites needs SSL.
Thanks for any clarification on the topic.
Edit: Some sources for my worries:
http://symbiosis.bytemark.co.uk/docs/symbiosis.html#ch-ssl-hosting
Is it necessary to have dedicated IP Address to install SSL certificate?
There's no such thing as "SSL certificate". The term is misleading. X.509 certificates can be issued for different purposes (as defined by their Key Usage and Extended Key Usage "properties"), in particular for securing SSL/TLS sessions.
Certificates don't require anything in regards to sockets, addresses and ports as certificates are pure data.
When securing some connection with TLS, you usually use the certificate to authenticate the server (and sometimes the client). There's one server per IP/Port, so usually there's no problem for the server to choose what certificate to use.
HTTPS is the exception — several different domain names can refer to one IP and the client (usually a browser) connects to the same server for different domain names. The domain name is passed to the server in the request, which goes after TLS handshake.
Here's where the problem arises - the web server doesn't know which certificate to present. To address this a new extension has been added to TLS, named SNI (Server Name Indication). However, not all clients support it. So in general it's a good idea to have a dedicated server per IP/Port per domain. In other words, each domain, to which the client can connect using HTTPS, should have its own IP address (or different port, but that's not usual).
SSL certificates do not require a dedicated IP address. SSL certificates store a so called common name. Browser interpret this common name as the DNS name of the server they are talking to. If the common name does not match DNS name of the server that the browser is talking to, the browser will issue a warning.
You can get a so called wildcard certificate, that would be admissible for all hosts within a certain domain.
...following up on #Eugene's answer with more info about the compatibility issue...
According to this page from namecheap.com SNI does not work on:
Windows XP + any version Internet Explorer (6,7,8,9)
Internet Explorer 6 or earlier
Safari on Windows XP
BlackBerry Browser
Windows Mobile up to 6.5
Nokia Browser for Symbian at least on Series60
Opera Mobile for Symbian at least on Series60
Web site will still be available via HTTPS, but a certificate mismatch error will appear.
Thus, as we enter 2016 I would venture to stick my neck out there and say, "If you're building a modern website anyway (not supporting old browsers), and if the project is so small that it cannot afford a dedicated IP address, you'll probably be fine relying on SNI." Of course, there are thousands of experts who would disagree with this, but we're talking about being practical, not perfect.
The ssl certificate commmon name has to match the domain name. You don't have any requisite over the ip address, unless it's a limitation imposed by the certificate provider or the http server software.
Edit: looking into the web, it seems that the rumor has been spread because Apache's ssl plugin doesn't have (at least it didn't have in 2002) any mechanism to use different certificate based on the hostname. In such scenario you would have to run two different Apache web servers on the two different IP addresses.
Anyway in your configuration you shouldn't have any problem using only one IP because you don't have to use two different certificates (because you plan to use a wildcard certificate).
I would try anyway configuring the webserver with a self signed certificate before spending money for a second ip or certificate.
Edit 2: reference apache documentation:
http://httpd.apache.org/docs/2.2/vhosts/name-based.html
It seems like now (apache >= 2.2.12) it is supported
I'm pretty new to the https world, so bear with me.
There are 2 web-servers involved:
Webserver1 has been in the organization a few years and is hosting/running multiple websites with https encryption (app1.ourcompany.com, app2.ourcompany.com, etc). It has a valid, signed certificate.
Webserver2 is a new server, for which I am responsible. I am tasked with setting up https and getting the certificate, etc. It has a web app running on it, but it does not have a domain name (only has an IP address)...which as I recently learned, is a requirement for a signed certificate.
What I'd like to know is this -- is it possible to set up a site on Webserver1 that points to the site I'm hosting on Webserver2 (ie SiteOnWebserver2.ourcompany.com) which also utilizes the Webserver1's signed/verified certificate?
Thanks for your time, SO gurus!
--Dan
A regular SSL certificate is valid for only a single domain name (such as app1.ourcompany.com). If this is the type of certificate currently being used then the existing SSL certificates will not work on your new server. If you did try this you would get an error in the browser saying that the site's domain name doesn't match the name in the SSL certificate.
The other option is to use a wildcard SSL certificate. These kinds of certificates are assigned to a certain parent domain (like ourcompany.com) and will work for all subdomains. This kind of certificate would work for app1.ourcompany.com, app2.ourcompany.com, as well as your SiteOnWebserver2.ourcompany.com.