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.
Related
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 bought the ssl certificate, added the ssl endpoint, changed the CNAME in my DNS to redirect to the ssl url provided by Heroku
Going to http://thekds.org Redirects me to https://kappa-delta.herokuapp.com instead of https://thekds.org. WHY IS THIS???
When you use the SSL:endpoint you can't access the site on the URL assigned to the SSL endpoint so you can't implement a redirect here. You need to have to DNS records CNAME'd to the herokussl.com address that was provided when the endpoint was added.
I'll also add, you need to ensure that because you want to use the apex record (ie thekds.org) that you need to use a DNS provider that supports using CNAME records there. DNSimple, DNSmadeeasy, PointDNS to name a few support this record type.
I have a domain which we'll call www.mydomain.com for reference. I have a subdomain at m.mydomain.com for people who want to view the website via their mobile devices. My users are logging into this site so I wanted to protect their credentials if possible. Because of this, I purchased an SSL certificate.
I'm not an SSL certificate guru, so I may be misunderstanding something. I thought that I could have a single SSL certificate for my domain. However, when I attempt to access https://m.mydomain.com I get redirected to https://www.mydomain.com instead of seeing the content that is at http://m.mydomain.com. In other words, here is a list of my configurations and results pulled from IIS 7:
Site Name Binding Type Host Name Port IP Address Result via Browser
--------- ------------ --------- ---- ---------- -----------------------------------
MySite http 80 ww.xx.yyy.zz http://www.mydomain.com works fine
MySite https 443 ww.xx.yyy.zz https://www.mydomain.com works fine
MyMobileSite http m.mydomain.com 80 ww.xx.yyy.zz http://m.mydomain.com works
My first hunch was to add a new binding of type https to MyMobileSite on port 443. However, in the process, I noticed that I'm prompted to select an SSL certificate. I'm concerned that if I select the SSL certificate associated with MySite, it will break that binding. Once again, I do not fully understand SSL certificates. Can I use the same SSL certificate across multiple IIS Sites and multiple binding as long as they share the same domain? Can I go ahead and create the binding like I was thinking? My main concern is that I break something and being unable to reverse it.
Thank you!
no the fact is that certificates are used to verify that your not using someone else's ip (spoofing) i suggest using linux and self signed ssl certificates but if your using windows thats fine too just use ssl on all your domains as long as there on same (external) IP,
hope this helps.
PS SSL is just a way of making sure security encrypted protocols are in effect between server and client.
I always recommend having both :443 and :80 for everyone to choose how they connect except if you are running sensitive data streams for money transfers etc, then defiantly make sure it uses secure (443 port) and never port 80 (unsecured connection).
It all depends on the type of certificate you purchased. Usually your lower costs cretificates are tied directly to one domain/sub domain name. However there are certificates that you can buy for instance the
http://www.verisign.com/ssl/buy-ssl-certificates/subject-alternative-name-certificates/index.html
Depending upon your organizations policy on purchasing, i would almost just suggest buying a seperate one for the Mobile site
AFAIK, SSL is assigned to a single domain name (maybe several subdomains via wildcard).
On the other hand i heard that the webserver does not see the domain before it serves the ssl?
If I have multiple domains running as vhosts on one IP address:
Q1: Can the webserver serve the appropriate respective SSL to the sites?
Q2: Is there a way to have only one multi-domain SSL serving two domains on one IP?
Illuminate me out of confusion brought upon me by this seemingly self-contradictory quote:
Regular SSL Certificates are issued for a single FQDN (Fully Qualified
Domain Name). The domain using the certificate has to have its own
unique external IP address from which to be served. In practice, this
means that if you have multiple domains on a single IP address/server,
then you had to install a separate certificate on each domain you
wanted to secure.
The reason for this is the use of 'Host-Headers'. They allow a
web server to use a single IP address to serve many separate sites
with different FQDNs. They do this by identifying the incoming request
for a webpage, and routing it to the correct site accordingly.
When an SSL connection is initiated, the server must send a
certificate to the client - before it knows the host-header of the
request. The only identifying piece of data it has is the requested IP
address. As such, two or more sites on one IP address cannot use
different SSL certificates....
Q1> the web server doesn't need to know the domains embedded in an SSL cert. only the browser does since it's the one making sure the domain in the certificate matches the domain in the address bar. The web server just serves up the cert bound to the ip address, regardless of what domain is in the certificate.
Q2> what you describe is a SAN or UC certificate. They are designed to do what you stated, namely allow multiple domains to share one cert on one ip address. Check out this link on Subject alternative names for more info
I have a question, I fear the answer.
I have:
a top level domain name (free from Tokelau, a territory of New Zealand, .tk, where else?),
a free 2 year ssl certificate from startSSL.com,
a free hosting package.
Now I jumped through every hoop startSSL wanted (admittedly wasn't too difficult), to get me my 2 year ssl certificate, and now I fear I have encountered a final barrier to success that might still stall my plans. I dreamt of a corner certificate stating "Secured by startSSL". I got the code snippet and everythings, and have pasted it into my website.
Problem. my host is not so keen on a free package to allow me to ssl.
As far as I know you need access to some config files to allow this to happen?
or can you just like with .htaccess and .htpassword files do the setting on your webhost?
Also you need a static IP. Are there any workarounds?
Or am I dreaming? Anyone with advice?
SSL Requires some files and configuration changes, pointing to the files.
Also, the static IP is required because with an encrypted request, there's no way to know to what host the request is intended without decryption. The use of a static IP address gives that request a destination.
To clarify: when using virtual hosts, multiple hosts will share the same IP address, so when a request comes in, the first two lines are:
GET /path/to/resource HTTP/1.1
Host: www.example.com
Apache (or any web server), looks at the 'Host' field to determine how to route the request. If the request is encrypted, there's no way to determine how to route the request, and you need to know what certificate to use in order to decrypt it.
Forget it. If your host doesn't have SSL configured, you have no chance to add it without their help
There are two problems with your proposed set-up.
Free hosts generally don't provide a control panel interface to allow installation of SSL Certificates (at least I've never seen it) as this requires either their help on the back-end or VPS / Dedicated Server access from the front-end.
Static IP address is a must for SSL certificate installation.
From webserver perspective, SSL cert is about a port and an IP address, even when being used with Name-based virtual hosts.
SSL is about the IP the matching the cert and domain in the URL/request(to verify the cert).
You would have to give a second SSL cert different port or different IP address on the webserver.
Alternatively, you can also get multi-domain and wildcard certs that allow different hostnames or domains to match the cert with different client request URLs, but the cert is still the only thing on that port/IP of the webserver.
Just my $.02