Wildcard SSL Certificate for subdomains / sub.sub.domain.com - ssl

I've got approximately 9 web servers running Ubuntu 12.04 with openssl.
all have the same primary domain of whatever.com , Although some are sub.whatever.com and others are sub.sub.whatever.com
Is there a type of SSL Certificate which can be used on all domains / sub domains ?
So I could install it on sub.sub.sub.sub.whatever.com if I wanted to?

Wildcard SSL only works on subdomain.domain.com and you can just add sub.sub.sub.domain.com as SANs to this certificate. Right now I'm using https://www.globalsign.com/ssl/multi-domain-ssl/ its quite expensive but its worth it.

Related

CloudFlare Error 521 only if setting ssl mode to full

I'm using CloudFlare SSL. when I set SSL to flexible everything works fine.
But if I use full SSL mode this error occurs instantly:
Note that I set the certificate and the key in my cpanel ssl section and I think everything is done ok.
Why this is happening and how to fix it ?
It is quite simple. All you have to remember is:
Flexible - there should be no SSL installed for that domain on the server ( no VHOST for port 443 either ).
Full - there should be an SSL installed for that domain, but it does not have to be a valid one ( you can use a self-signed or expired SSL ).
Full Strict - there should be a VALID SSL installed for that domain on the server ( it has to be absolutely a valid and active SSL ).
So, depending on the SSL you have on your domain server, just set the Cloudflare SSL to one of the above options. If you believe that everything is okay and you still get an issue, I would suggest reaching your web host to check that further for you.

Custom TeamSpeak IP no longer working after adding SSL

I am currently using CloudFlare and recently added an SSL certificate to my script.
Before hand, I added an A record (proxied with CloudFlare) that pointed to my TS IP. It worked like this: ts.domain.net:PORT
However, after I added the SSL cert, it doesn't seem to work anymore.
If it matters, my main site IP is also (of course) proxied under CloudFlare
Thanks!
Every certificate contains one or more Subject Alternative Names. You can use the certificate only on domains that are listed as SAN within the certificate, as long as you don't have a wildcard certificate that can be used on a all subdomain, eg. *.mydomain.net.
Therefore for your TS server you need a certificate that contains the SAN ts.domain.net. If your current certificate is only for domain.net you need another certificate for your Teamspeak subdomain.

wildcard certificate does not work for sub-domain

I have created a wildcard certificate that works for for xxx.domain.com but not for aaa.bbb.domain.com
when creating the certificate:
Common Name (e.g. server FQDN or YOUR name) []:*.domain.com
but it seems to not be enough.
Wildcard SSL certificate matches only one level. See
Problems with SSL and multi level subdomains
wildcard ssl certificate does not cover www version, how do I fix?
https://serverfault.com/questions/296390/ssl-domain-problem-for-signed-asterisk-certificates
https://serverfault.com/questions/645230/why-does-my-wildcard-ssl-certificate-cause-a-domain-mismatch-error-on-a-second-l
https://serverfault.com/questions/87869/ssl-certificates-for-subdomain-example-com
https://security.stackexchange.com/questions/83245/ssl-cert-for-sub-domain-com-and-www-sub-domain-com
https://serverfault.com/questions/104160/wildcard-ssl-certificate-for-second-level-subdomain

SSL: where is the certificate hosted? when does the verification occurs?

I am quite confused here:
I use DNSMadeeasy to manage my DNS. I have two apps.
One is Heroku hosted, and has https on https://example.com - Heroku has many great tutorials to setup the certificate, it hasn't been a problem.
The other one is a wordpress, hosted in 1and1 (though it shouldn't matter here), and is reachable at http://subdomain.example.com and we want it to be available at https://subdomain.example.com
1and1 does sell SSL certificate, but their automated setup works only when one uses their services for DNS also, as they say. Their support says it should be DNSMadeEasy which should be hosting our SSL certificate. I have the feeling it is not true, because for https://example.com, DNSMadeEasy was never involved.
Questions:
When does certificate querying occurs? Before, After, or in parallel of DNS resolution?
Who is hosting a certificate? The DNS provider? The server (accessible like a sitemap.xml at the root for instance)? A third party?
To enlarge the case, in general if I have a personal server with a fix IP, how can I communicate through https with a valid certificate?
In my case, how can I get my way out of it to make https://subdomain.example.com work?
You are right for not believing the 1and1 suggestion.
To answer your questions:
When does certificate querying occurs? Before, After, or in parallel
of DNS resolution?
A client resolves domain name to an IP address first. So DNS resolution happens first.
Who is hosting a certificate?
The server (in simplistic terms) hosts the certificate.
When a client wants to connect to your site (via HTTPS) it will first establish a secure connection with that IP address on port 443 (this is why usually (without SNI) you can only have one SSL certificate per IP address). As part of this process (which is called handshake) a client can also specify a server name (so-called server name extension) - this is a domain name of your site. This is useful if you have an SSL certificate that is valid for multiple domains.
A good/detailed explanation how it works can be found here
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
if I have a personal server with a fix IP, how can I communicate
through https with a valid certificate?
Your server will need to be able to respond on port 443 and have/host an SSL certificate for a domain that resolves to that IP address.
In my case, how can I get my way out of it to make
https://subdomain.example.com work?
You need to purchase a certificate for subdomain.example.com and install it on the wordpress server.
Usually in hosted solution like yours you have 2 options:
Buy the SSL certificate via the provider (1and1 in your case) - a simpler option, they will configure everything for you.
Buy the SSL certificate yourself. Here you will most likely need to login to your 1and1/Wordpress management interface and generate a CSR (essentially a certificate request). Then you purchase the SSL certificate using this CSR and then you can install it via the same management interface.
The process will look similar to this:
http://wpengine.com/support/add-ssl-site/

Purchased and installed ssl certs but still indentified as *.herokuapp.com

I followed the instructions to the letter here -- https://devcenter.heroku.com/articles/ssl-certificate --, and they were helpful, especially since DNSimple is my registrar of choice. I got everything up and running as far as I know, purchased the certs (via DNSimple and RapidSSL), combined the crt and the CA bundle, and sent them up via the heroku client:
$ heroku ssl
www.website.com has a SSL certificate registered to /serialNumber=…
website.com has a SSL certificate registered to /serialNumber=…
But when I go to my apps (I even restarted them) they are still using the certs for *.herokuapp.com. Is there anything I've missed? Why would things be coming up as *.herokuapp.com?
From the top, here are the pieces provided to me from the related parties.
From DNSimple (on the cert details page) : Private Key
From DNSimple (on the cert details page) : Certificate
From RapidSSL's CA Download page (linked from DNSimple) : CA bundle "pem"
From email sent by RapidSSL / Geotrust : Web Server CERTIFICATE
From email sent by RapidSSL / Geotrust : INTERMEDIATE CA
I imagine that the "private key" is what I need in the second part of the heroku ssl:add dance: heroku ssl:add site.pem private.key
But it seems that I'm doing something wrong when I'm putting together the "pem" file for the first file I'm sending with heroku ssl:add. Of the pieces above - what needs to be combined in order for this to work?
I know this question is old, but I just hit the same problem and found the answer, at least in my case.
I had my DNS pointing to my-app.herokapp.com but the SSL endpoint is different. You can find the SSL endpoint like this:
$ heroku certs
Endpoint Common Name(s) Expires Trusted
------------------------ ---------------------------- -------------------- -------
osaka-5565.herokussl.com www.example.com, example.com 2014-05-18 09:32 UTC True
Your endpoint will be different from that. Once you change your CNAME and/or ALIAS records to point to the SSL endpoint, you'll get your own certificate instead of the herokuapp wildcard.
Make sure you're not viewing the naked domain name, https://yourwebsite.com is not supported with SSL on Heroku, whereas https://www.yourwebsite.com is.
If this ends up being the issue you'll have to make sure the naked domain name redirects to a subdomain like www.