Is there a way to have the https server return different certificates based on sni data?
So if the client advertises that it is connecting to a specific hostname , the system should respond with the correct cert, not always the same. I cannot create a common certificate with alt names for all hostnames, but I can store a certificate for each hostname the esp can be accessed from.
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've setup a SSL certificate w/ the common name, etc. as 'www.biglikeco.com'. I have set 1 cname in my dns to goto the main Heroku app area - what should the other CNAME record be? I I'm trying to get SSL working on 'www.biglikeco.com' also - is this possible (e.g. https://www.biglikeco.com as well as http://www.biglikeco.com) ?
Thanks.
SSL certificates are usually associated with an IP address, not a DNS record.
You need to associate the SSL certificate with your IP on the configuration of your web server. If you don't have an IP address dedicated to hosting the secure version of your site, you can rely upon Server Name Indication. Server Name Indication is an extension to the SSL certificate authentication process, such that the domain name AND the IP address are sent to your web server. DNS (and CNAME records) are not involved in this process, other than the initial name resolution.
Update:
You don't need a second IP address to host a secure version of your site. You can configure your web server to respond to HTTP and HTTPS separately. However, the SSL certificate is still strongly associated with your IP address. It cannot be redirected with a CNAME in DNS.
I am planning to add a SSL certificate to my app on Heroku. For that, I am planning to buy a wildcard ssl certificate. A requirement for that certificate is that I need to have a "dedicated IP address".
Afaik, I don't think I have a dedicated IP address as I am hosting my code with Heroku and I don't think I can be guaranteed an IP address of that machine.
Am I missing anything? Should I be looking at another kind of SSL certificate?
Thanks!
If your domain name is registered and pointing to Heroku as Heroku's documentation advises, then you should be able to get an SSL certificate for that domain name. Your SSL certificate authority should not require you to enter in an IP address. I can only speculate that it might say you need a "dedicated IP address" in order to discourage people from trying to get an SSL certificate for their residential cable modem, etc.
Can URLs be sniffed even though a client communicates with a server over SSL? I'm asking because I'm doing remote login & redirect to a physically different server via URL, and wondered if securing the communication via SSL would prevent replay attacks and the like.
The sniffer will know the IP (and probably hostname) of the server you're requesting from, and the timing/quantity of information transferred, but nothing else.
Yes, replay (and man in the middle) attacks are prevented by SSL if you don't trust a compromised root certificate.
An attacker can observe both the hostname (by watching your DNS traffic) and the IP address you're connecting to. The username, password and path part of the URL should not be available, however.
Of course, the client themselves always has access to this information.
The network sniffer would need both the public and private key to decrypt the SSL traffic.
SSL sets up an encrypted session between the two machines and then runs "ordinary" HTTP over that encrypted connection so they can see what physical machine you are connected to but beyond that can't see anything at all in your connection.
As others have said they can look at the DNS requests most likely to determine the hostname.
Also there are products out there which bypass this protection in a business environment by installing a new root certificate on the client machine and having a proxy server make the connection on your behalf, and then generating a "fake" certificate for the site generated using their root key to make the session to the browser so you appear to have a secure SSL connection to the server but in fact it's only to the proxy. You can look at the certificate chain for the connection to determine if this is happening but few people will bother.
So to answer your question - no the full URL can't be sniffed - but with access to the client machine it is possible to do it part way.,
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.