I have a certificate that is registered to the fully qualified domain name of a server on our intranet (webserver.domain.com). When our internal users hit this site via the fully qualified name, they go right in and aren't prompted that it's an invalid cert. If they browse to the web server via the hostname (non-fully qualified) they are redirected to the https version and no prompt is made there either. The part of my mod_rewrite that I'm missing is if someone connects to the web server via http's' with just the hostname. I can't seem to get that to rewrite to the FQDN. It doesn't rewrite and always prompts that the cert is invalid. Any help is appreciated. Thanks!
Here's an example of what I can't seem to match:
https://webserver/pubs/index.html
I need it to rewrite to:
https://webserver.domain.com/pubs/index.html
Unfortunately this isn't going to be possible - the prompt occurs when the connection is made, before mod_rewrite is involved.
If they OK the prompt, then you can rewrite to the FQDN.
Related
I have a wildcard certificate for *.domainname.com. I know that TLS sessions are set up before any URL rewrite rules happen. I have the URL test.domainname.com working fine and redirecting to https. But what happens when someone may type in www.test.domainname.com. Now they get "Your connection is not private" because the www adds one more level and makes the wildcard certificate invalid. I would like to strip out the www with a rule but the SSL check happens first. How do people handle this so that all URLs end up at the same place with no errors?!? I am using Windows Server and IIS...
I have a valid wildcard ssl cert for our (internal) domain - *.stmn.company.local
I have a site that I want to use with this cert, let's say - https://server.stmn.company.local
In firefox/chrome, if I navigate to that FQDN url, it works fine, I do not get an invalid cert warning or security warning.
However, if I navigate to "server/" or "https://server/" or "http://server/" (the trailing slash is necessary to tell firefox/chrome that this is an internal site and to go directly to it, without searching) I get an error in firefox that my certificate is not valid.
server uses an invalid security certificate. The certificate is only valid for *.stmn.company.local (Error code: ssl_error_bad_cert_domain)
This is unexpected to me because my search domain is configured with stmn.company.local so in theory any dns name I don't fully qualify should have that appended onto it?
bryce-e#channel:~$cat /etc/resolv.conf
search stmn.company.local company.local
nameserver 10.99.42.30
nameserver 10.99.42.31
Am I misunderstanding how search domain works, or SSL certs?
The domain name that is typed in the browser must match. You need to make your site accessible at the same url internally and externally, or modify your certificates to include all the names that will be used.
If routing is problematic, use of 'split' dns might be helpful. With that you can have a domain name resolve to a different ip address internally vs externally.
It isn't sufficient to just have the name resolve to the right ip.
I've got a home server that sits behind a dynamic ip address. I use a free dynamic dns service (http://freedns.afraid.org/) so that I can access my server via the following (fake) hostname foo.example.com
I use bluehost to host a separate domain, mycompany.com, and used their DNS settings to set up a CNAME to route traffic for mycompany.com to foo.example.com
What i want to do now is throw an SSL cert into the mix. The problem is I don't know how to go about getting the cert. Some companys (godaddy) want me to associate a domain to the cert. I don't know if that's mycompany.com or foo.example.com. Even if i pick one, it seems like the browser would complain about a mismatch.
Any insight would be great.
If the website gets accessed as https://foo.example.com you need a certificate for foo.example.com. If it gets accessed as https://mycompany.com you need a certfificate for mycompany.com. If it needs to be accessed with both names (like if one side would redirect to the other) you need a certificate containing both names.
I have a Debian server which is running a number of client sites. Most of these are not running SSL so accessing by HTTP is fine.
I have one customer with an SSL certificate and accessing their site via HTTPS is fine too.
The problem comes if you try to access one of the other sites with HTTPS you get directed to the other site that has the SSL certificate.
For instance, lets say we have the following sites on the server:
alpha.net
bravo.net
charlie.net (SSL)
delta.net
So as you can see, charlie is the only one with SSL, and irrespective of if you go to http charlie.net or https charlie.net, it works fine.
http to all the other sites is fine, but if you were to go to https alpha.net, it will initially come up with an Invalid Certificate error and let you continue but whilst it has alpha.net in the address bar, its actually showing the charlie.net site in the browser.
I have researched SNI and how if any other sites have SSL I'll need to put them all on specific IP addresses (something else I need to try to work out how to do as I have no idea) but I am not sure why this is happening or how I resolve it.
Has anyone else encountered this before and how did you get around it?
Many thanks,
Rob
This does not have anything to do with SNI, as you currently only have one HTTPS server. What happens, as you've stated in your comment, is that the alpha.net domain resolves to your server's IP. Your Apache server is set up to listen for requests on port 443 on this IP, and to serve the contents of charlie.net to these requests. (And the certificate error means that the browser noticed the discrepancy between the certificate's alleged domain name and the domain name used for the request.)
Redirecting from HTTPS to HTTP is probably more trouble that it's worth, since you would need valid certificates for each domain, lest you present your users with another security warning. This would entail creating virtual hosts for alpha.net:443 and so on, on an SNI capable server (i.e., later versions of Apache 2.2+ with openssl), and adding a redirection like so:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
Probably the easiest course for your problem is to use a different IP for charlie.net. With this setup, there would be no way for alpha.net (and so on) to display the contents of another site.
If you have multiple IPs on your server, use a unique one for the SSL site, all non-SSL sites share another IP.
Since SSL doesn't care what is the domain you are visiting, it only cares if the current domain is approved from the list of domains(Common Name) it gets from the Ip address.
I have an apache server with multiple named hosts all working fine for port 80 http traffic.
(A VPS with one unique IP address)
I have one domain that has a SSL certificate and that domain is configured to handle both http and https traffic.
However if someone accidentally adds https to the beginning of a none SSL configured URL I get a typical certificate warning error (expected) and then if the user accepts the error (depending on the browser) it displays the SSL site I have configured instead of the original non-ssl domain.
I've read up a bit about SNI, but I don't have certificates for each of the other domains and would rather the server either not respond to the SSL request on anything else but one specific domain or redirect to the http version of the site.
Suggestions please as to how I approach this.
Kind regards, Spencer
For security reasons, what you're trying to achieve cannot work.
The browser (which implements the mechanisms to check the certificate) cannot know whether the user typed https:// instead of http:// accidentally or intentionally. Since it's ultimately up to the users to check that https:// is used when they think it's required, browsers should simply perform the actions requested by the users.
A redirection from https:// to http:// should always start with a valid https:// connection. SNI won't help you much there if you can't have valid certificates for the initial connection.
Otherwise, it would be fair for browsers to assume there may be a MITM attack in progress. Typing in https:// explicitly (or using HSTS) is the only reliably mechanism against MITM tools like SSLstrip, which would otherwise be capable of downgrading (or preventing an upgrade from http:// to https://).