Currently, two different websites are hosted on different ports in the same server IIS8. Now we would like to move those websites on HTTPS 443 in the same server IIS and two different domains are available www.example1.com, and www.example2.com thus which type of SSL certificate need? Does the different certificate work for each?
IIS 8 and above supports SNI, so multiple sites can bind to the same IP:443,
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability
If you find your attempts fail, you can go deep to Windows HTTP API layer to see if you get SNI certificate mappings configured properly,
https://docs.jexusmanager.com/tutorials/https-binding.html#background
or generate a diagnostics report,
https://docs.jexusmanager.com/tutorials/ssl-diagnostics.html
There isn't special requirements on certificates as long as they are valid for server authentication.
You can use the 443 port with both different websites in iis with different domain names and server Name identification setting
you can buy any trusted root CA server certificate for your domain and you have to buy two different certificates.
Related
I cant seem to run multiple sites using the same IP with different ports and different ssl cert.
site a is fine but site b is returning SSL_ERROR_BAD_CERT_DOMAIN because it's returning site a's ssl cert.
This is the error I get when trying to use it on the same ports hence I use different ports for the domains
Here are my thoughts:
First of all SSL certificates are most commonly issued against domain names instead of IP addresses.
In your scenario you have one IP address so only one certificate can be issued against one IP address.
Options:
Get multiple SSL certificates for your website domains assuming your websites will be hosted on different domains e.g. example1.com, example2.com
Get wild card ssl certificate and then use it for your multiple websites assuming your websites will be hosted on sub-domains e.g. site1.example.com, site2.example.com
So the solution provided by Moshin Mehmood did resolve the issue.
Any site on IIS will have to use SNI and there is no reason to supply a specific IP if all the sites use the same one, IIS will give an error about not having any default ssl bindings but that is a legacy thing and not cause for concern.
Thank you very much Mohsin.
I am hosting Tableau Server on Amazon Web Services (AWS) EC2. My domain name is ec2-xx-xx-xxx-xx.xx-xxxx-x.xxxxxxx.amazonaws.com. I would like to convert http to https, so I want to get a SSL certificate. When I asked a certificate authority (CA), they told me that my domain includes "amazonaws.com", so I couldn't get a SSL certificate. I then tried to get a SSL certificate from AWS, I received an error message.
Error message.png
This was due to the fact that I couldn't request a certificate for Amazon-owned domain name ending in "amazonaws.com".
Does anyone know how to deal with this issue?
Sincerely,
Kazumi
Looks like you need to understand the basics of the process of purchasing a domain name, assigning an IP address to the domain name, purchasing an SSL certificate etc.
Below steps are the easiest and the cheapest way to make your endpoint be served by SSL on AWS infrastructure:
Purchase a domain name eg. knozawa.com from AWS Route 53
Create a new SSL certificate free of cost using AWS
Certification Manager (ACM)
Add your EC2 instance which hosts the Tableau server behind an ELB. The ELB
should be configured to accept traffic over port 443 only. Select
the certificate created using ACM to serve for SSL traffic over port
443.
Go to Route 53, and created a hosted zone entry like
tableau.knozawa.com and add the ELB alias to the entry.
And you are done! You can now access your Tableau installation on your own domain name, serving traffic over SSL on the link https://tableau.knozawa.com
This will probably cost you and additional USD 12.00/year for the domain name, $10-$20 per month for ELB based on traffic.
I am working to setup my application to watch calendar events through Google's Calendar API. In doing so I must setup a "Push" endpoint on my server that has a valid SSL certificate (not self-signed).
My production environment is running on Heroku so setting up an SSL cert was easy using Expidited SSL. I have two CNames setup in GoDaddy, one for my production application and one for my development environment tunneled through ngrok. I'm using the paid ngrok feature of white labeled domain tunneling (dev.mydomain.com).
Host Points To
www saga-1234.herokussl.com
dev ngrok.com
The problem is that my ssl certificate is recognized when you hit the production application (www.mydomain.com), but it uses ngrok's certificate when you visit the development application (dev.mydomain.com).
How can I setup my ngrok tunnel to use my ssl certificate?
Ngrok's white labeled domain does not support HTTPS if you are using your own domain. Simply because it serves it's own certificate, where you need to serve your domain's. That's why you are getting certificate mismatch issue.
Here's what you could do to watch calendar events on your dev machine:
Point ngrok.mydomain.com to another server, let's say a new EC2
micro instance
Point wildcard CNAME to ngrok.mydomain.com
Compile ngrok server and client to use your certificate (rather than
ngrok.com)
Run the ngroku-server on EC2 instance
On your dev machine config the client to use ngrok.mydomain.com instead of ngroku.com
Run ngrok -subdomain=dev 80
Your local dev machine's 80 port should be accessible via https://dev.mydomain.com
This is really cool and is very helpful when debugging Google's webhooks, which require valid HTTPS and a verified root domain name.
Another interesting trick is to use CloudFlare's universal SSL to have a valid https://dev-machine.mydomain.com pointing to your dev machine without purchasing a certificate. The steps are exactly the same except that you need to issue your own certificate for ngrok client-server communications and use CloudFlare's Flex SSL for dev-machine.yourdomain.com.
ngrok has a new feature that tunnels and terminates SSL. Thus you can use your own domain and HTTPS. No need to open ports in your router or PC. They call it TLS Tunneling. The following is a link to a GitHub repos that describes how to do it.
How to use your own domain to access your home PC over the internet. Use HTTPS without raising SSL errors.
I'm using my friend's dedicated server where he hosts 2 of his websites to host my own, but I'm not familiar with registering domains, and I can't get my domain to point to a specific port I use so that my website doesnt clash with his. He has 2 websites that according to IIS are using the SAME PORT, I installed XAMPP so I had to use the 8080 port, how did he register two different domains for websites hosted on the same ip under the same port? and how do i point my domain to my 8080 port? (using apache)
You need to use host headers to prevent conflicts if you're sharing the same IP, else you need your own IP. With the appropriate dns settings, and host headers setup in iis, you'll never conflict with his sites (that should also be using host headers).
We have two different ldap providers in two different physical office locations.
When I connect my laptop to one location and I 'retrieve from port' (in Websphere 6.1) to import the SSL cert of the ldap provider, I can authenticate to the respective ldap with no problems. If I take my laptop to the other office (that uses the other ldap provider by default) and I plugin my laptop, my WAS on my laptop will not start because it says 'no trusted SSL cert found'.
If I 'retrieve from port' again and re import the cert then it works again.
Note that my WAS always try to connect to one ldap, it simply has no use for the other one.
If I go back to the other office I get the same error until I reimport from that location. The ldap connection point is ldap.example.com:636 and is pingable in both locations with the same FQDN.
But when pinged it resolves to a different IP address in each office location. Why do I see that behavior?
Are SSL Certs somehow bound to a specific IP address?
If yes, then I need to maintain a different set of certs for each office location, right?
Note that, there is no way to adjust the DNS servers to resolve the hostname to the same IP address, I checked.
Can someone provide some insight?
SSL certificates are bound to a 'common name', which is usually a fully qualified domain name but can be a wildcard name (eg. *.example.com) or even an IP address, but it usually isn't.
In your case, you are accessing your LDAP server by a hostname and it sounds like your two LDAP servers have different SSL certificates installed. Are you able to view (or download and view) the details of the SSL certificate? Each SSL certificate will have a unique serial numbers and fingerprint which will need to match. I assume the certificate is being rejected as these details don't match with what's in your certificate store.
Your solution will be to ensure that both LDAP servers have the same SSL certificate installed.
BTW - you can normally override DNS entries on your workstation by editing a local 'hosts' file, but I wouldn't recommend this.
The SSL certificates are going to be bound to hostname rather than IP if they are setup in the standard way. Hence why it works at one site rather than the other.
Even if the servers share the same hostname they may well have two different certificates and hence WebSphere will have a certificate trust issue as it won't be able to recognise the certificate on the second server as it is different to the first.
Most SSL certificates are bound to the hostname of the machine and not the IP address.