I created Wildcard certificate to support my site domain and subdomains.
The new certificate works for my subdomains (e.g www.mydomain.com , sub.mydomain.com)
But when I try to get to mydomain.com I get certificate warning: "the certificate is only valid for *.mydomain.com"
Is it a problem with my configuration or just the Wildcard certificate doesn't support it?
For supporting both example.com and subdomain.example.com the certificate needs to include both *.example.com and example.com as subject alternative names. I assume that the last one is missing from your certificate.
I guess you have purchased wildcard ssl certificate from thawte or symantec, which does not support equally www and non-www. In the past, I purchased thawte wildcard certificate and faced the same type of issue. I just discussed with my vendor to get the solution, they gave me technical support instantly and suggest alphassl wildcard -
https://www.ssl2buy.com/alphassl-wildcard.php. After that, I switched over to alphassl wildcard that works fine on my both domain names mydomain.com, www.mydomain.com as well anything.mydomain.com.
Related
I have just bought an SSL Certificate for my website from azure. when setting up a certificate under "Naked domain hostname" i entered the domain name WITHOUT "www".
Currently if i were to view my website with https://xyz.ca, it works just fine and it says it is secure, but if enter www.xyz.ca i do not see anything.
To atleast view the website with www.xyz.ca, i have removed HTTPS:// only request. However now this makes website un-secure.
Question
1. what will be the best way to make www.xyz.ca secure using the same certificate that i have bought?
2. if there is any other solution available, that will be fine too.
I am attaching some screenshots to understand better:
In fact a cert CAN support MANY domains. Now, whether this is something that you can add for free with the SSL provider you have chose is a different question. Certificate Subject Alternate Name(s) are what is used for this. For example the cert for this site allows stackexchange.com AND stackoverflow.com and a number of others and sub-domains too.
A valid SSL certificate must match the access FQDN domain name.
One Standard certificate only could be used for one FQDN domain name, such as www.xyz.ca while one WildCard certificate could be used for all like *.xyz.ca FQDN domain name, so usually we use the same WildCard certificate for all different services. More information about SSL Certificate Names
As the comment point it out, instead of buying one via the Azure Portal, you can get a free one via letsencrypt.org
Update
When you purchase an app service certificate in Azure for a root domain, by default, Azure supports hostname as a root domain name and www subdomain. You do not need to purchase another certificate. In this case, you already have two hostnames assigned to the site. You just bind the certificate for each. If you don't see the domain name(s) in the Hostname dropdown, try refreshing the browser page or change another browser.
I have created few subdomains for my domain like api.example.com, dev.example.com and www.example.com. For every subdomain I created an virtualhost in Nginx.
But now the problem is when I visit a domain which does not exist it should be redirected to www.example.com. But this is not the exist instead I am getting an error page that the sub domain does not have an secure connection. Since I am using Let's Encrypt, I get this message all the time for sub domains which is incorrect. I contacted my DNS provider and they told me your settings are correct you have to correct your web server configuration. They added a CNAME.
Now I do not know how to add this in my nginx configuration.
So... you type the https ://incorrect.example.com in your browser?
If so, I think the problem cannot be solved.
In the article (https://community.letsencrypt.org/t/can-i-use-letsencrypt-in-more-than-one-subdomain/16588/8) they said
Let's Encrypt does not currently offer "wildcard" certificates. So you will need to be able to list all the domains you want a certificate for, you can't (as you can with some of the pricier paid certificates) get just one that works for every possible name in your domain. With Let's Encrypt you'd need to issue new certificates for any new names you needed.
That showed you can't set all the certificate of incorrect subdomains...
But if you just type "http ://incorrect.example.com", It can be success redirect without error page.
If error page continue occurring, please post your conf of nginx.
I see two separate questions -
security warning can be removed using a wildcard certificate from letsencrypt. Please see detailed instructions here
Redirect non-existent domains to www.domainname.com
You need multiple server sections in place -
Have server {} sections for each existent domain to port 443 (HTTPS port)
Have one server {} section for *.domainname.com to redirect to port 443 or www.domainname.com
If you are running an app that dynamically uses subdomains (for each customer) the app should also implement the redirection to www.domainname.com for non-existent subdomains.
I have a domain www.example.com , and I have an ssl for it.It is working fine.But I have unlimited subdomains,which comes as user.example.com
But even if I have ssl for example.com , the subdomains shows as if doesn't have ssl.I have searched online and found that there is something called wildcard ssl which is very costly.Is there some way I could use my current ssl or possibly an normal ssl(not wildcard) for my sub-domains ?
I wanted it this way https://user.example.com/
Im pretty new to ssl and it seems the wildcard ssl are very costly
Wildcard ssl can be used with multiple subdomains of a domain.So it's cost is high. I f you have multiple subdomains under a domain, you need to purchase a wildcard ssl.
Wildcard certificates secure the common name and all subdomains at the level you specify when you submit your request. Just add an asterisk (*) in the subdomain area to the left of the common name.
No, this won't work.
Ways to fix:
Buy an expensive wildcard certificate as you mentioned
Buy another SSL certificate for user.example.com AND purchase and setup an additional IP address from your provider - because you can only have one SSL host per IP address (the hostname request parameter is itself encrypted).
We have two A records pointing to same public IP address as:
www.example.com IN A 192.*.*.*
example.com IN A 192.*.*.*
We have certificate issued by Verisign to www.example.com. Now when the user types https://www.example.com/xyz, everything works fine as expected.
But when we use https://example.com/xyz, the browser throws an error:
"There is a problem with this website's security certificate"
And asks the user to make decision if they trust and want to go ahead.
Now what should be best practice here:
Change certificate and get wildcard certificate *.example.com
Use following setting at DNS:
www.example.com IN A 192.*.*.*
example.com IN CNAME www.example.com
Write a HTTP module in .Net pipeline to redirect user if they type example.com/xyz to www.example.com/xyz. I know this is not recommended.
We would like to do something like what chase.com is doing. If you type chase.com it takes you to https://www.chase.com/.
None of the above. You should get SSL certificate that covers two domains: www.mydomain.com and mydomain.com.
As per your proposals:
1) Having wildcard certificate for a single domain of *.mydomain.com will still give you an error when opening mydomain.com without any prefix. You may of course get a multidomain certificate for *.mydomain.com and mydomain.com
2) For the sake of SSL, it doesn't matter CNAME or A - DNS used to get the address (A record) of your webserver, afterwards browser still expects SSL certificate to match exactly what you type in the address bar.
3) That would work for http requests, but when user types https://mydomain.com, browser checks SSL certificate before it processes the redirection request, and will still show the warning.
P.S. You have this problem because CA industry is totally screwed. Their product pages all look like "super 256-bit encryption" (certificate have nothing to do with encryption strength), mobile support (be it mobile or mainframe, certficate is all the same), and "a free site-seal included" (site seal is a great name for a CA advertisement placed on your site).
All the not important things like is it's CRL or OCSP, or which domain names it covers at all - never mentioned.
I have a webserver (IIS) with an SSL cert for *.mydomain.com
This works perfectly for https://anysubdomain.mydomain.com/ but going to https://mydomain.com/ causes a certificate mismatch error in IE (has not been tested in all other browsers).
Is there any way to work around this, or is it simply a problem with the way IE treats the wildcard in the certificate we have to live with?
The only way to remove the error message when accessing the site at https://mydomain.com is to put the base domain (mydomain.com) in as a Subject Alternative Name in the wildcard. Several certificate providers will add this for free (including DigiCert and Comodo) but you will need to reissue your certificate.