I have a website with two different certificates. One for official use so the user doesn't see a self-signed alert. And one for internal use for private subdomains (for phpmyadmin, roundcube and so on). These subdomains are only for admin use, so it seems useless to me to spend money on a wildward-certificate. Therefor the wildcard-Certifitae is Self-Signed and I have memorized the hash.
Also I got an etherpad-Installation on that server on a different port than http (not a difefrent subdomain). Etherpad now seems to send this header "Strict-Transport-Security: max-age=31536000; includeSubDomains" which is just dumb, because i couldn't find an option to turn off the "includeSubDomains".
Now when I was in my pad and then try to use my admin-Subdomains I get an Error because of HSTS, without the option to set an exception and therefor these are now unusable for me.
Does somebody has an idea how I can get rid of the "includeSubDomains" in the etherpad installation?
I would be glad if someone could help me. Thank you.
It's a tad old, but I would like to point out the better alternative: install the certificate of the (self-signed) CA that you used to sign you own certificate as a trusted CA in your browser.
I just share the CA certificate on my webserver, and download/install it using the IP-address to avoid the HTST-trigger. You can point your browser to
http://1.2.3.4/my_certificate.pem
and your browser will ask you for what you want to use that certificate. If you set it to be allowed to sign websites, and the CN in your certificate matches the hostname your using it for (roundcube, phpmyadmin, etc), your browser will happily accept your self-signed certificates, even when HSTS is enabled.
Related
Can I use a certificate from letsencrypt to sign local certificates?
I'm annoyed when accessing routers and APs at 192.168.x.x to get security warnings.
I could create my own root cert, and import it into all my browsers etc, and create certs for all the local servers.
But I'd rather have the chain device -> www.example.com -> letsencrypt -> root
Then also guests could use my local servers/services without this security error.
No, you can not because the certificate issued to you by letsencrypt will not have the keyusage certificate signing enabled. Without this attribute in the issuer, any browser or SSL client musth reject the certificate.
If this were possible, anyone could issue valid certificates for any server simply by having a valid certificate from a trusted CA
If you want to issue certificates for your local servers you will need to create your own CA and include the root certificate in the truststore of each client
Yes, you can... but not like that
Yes, you can get certificates for servers on a private network. The domain must be a real domain with public txt records, but the A, AAAA, and CNAME records can be private/non-routable (or in a private zone).
No, the way to do that isn't by using Let's Encrypt certificates to sign local certificates.
You can accomplish exactly what you want to accomplish using the DNS-01 challenge (setting txt records for your domain).
Who is your domain / dns provider?
Immediate, but Temporary Solution
If you want to test it out real quick, try https://greenlock.domains and choose DNS instead of HTTP for the "how do you want to do this" step.
Automatable Integration
If you want a configurable, automatable, deployable solution try greenlock.js (there are node plugins for Cloudflare, Route 53, Digital Ocean, and a few other DNS providers).
Both use Let's Encrypt under the hood. Certbot can also be used for either case and can use python plugins.
Possibly related...
P.S. You might also be interested in a service like Telebit, localtunnel, or ngrok.
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/
This problem is driving me mad but hopefully to you people it may be simple.
This is what I have done:-
Created a new (self-signed) SSL certificate in Plesk 12 to secure the panel.
Set it to use this as the panel certificate.
Changed the ip address to use this new certificate in Tools/IP Addresses
I have checked the sites ssl certificate on numerous online checkers and they all report the certificate is fine (although it being self-signed).
But whenever I browse to the panel I still get 'Your connection is not private'
The trouble is then that the PEM encoded chain, which I believe to be the certificate it's using, is not the self-signed certificate I created. Then after a certain period of time, approx 5 mins, even when I'm still using the admin it will go to 'Your connection is not private' again and show a different PEM encoded chain.
Please could someone help as this drives me crazy when I'm using Plesk.
The sever is running CentOS 6.6 and the servers default address is sris1.co.uk
Thanks in advance.
Most probably, you are accessing both https://sris1.co.uk and https://www.sris1.co.uk, while certificate is issues for www. domain, and it's understandably failing when you access just sris1.co.uk, and browser thinks, that you are being tricked, since cert is issued for different site.
I've never met such problems in Plesk, so, this is only thing, that I can guess from provided information.
I have a domain with a wildcard SSL certificate (https://domainA.com). I have users who use custom subdomains (https://user1.domainA.com). I have users who wish to use custom domains that point to their subdomains (CNAME records from https://domainB.com to https://user1.domainA.com).
The problem with these custom domains is that they throw an SSL warning in the browser, as the domain name on the SSL certificate (https://*.domainA.com) does not match the domain name being used to access the page (https://domainB.com).
Enter Cloudflare.
By using Cloudflare's Full SSL service, on https://domainB.com, I can suppress the SSL warning so users experience no problems. I know that the SSL warning exists (as disabling Cloudflare will cause the warning to re-appear), but Cloudflare silently dismisses the warning and proceeds with the encryption.
Also, by using Full SSL, I am theoretically encrypting traffic completely between the user and the server.
My question has to do with the security/legitimacy of this solution, to apply SSL encryption any domains (https://domainB.com, https://domainC.com) that users may wish to use to reach their pages (https://user1.domainA.com).
Is this secure? Is this safe? Is this responsible?
There are a few factors to this.
One is how far you trust CloudFlare. They will see your users' traffic in plaintext, after decrypting the tunnel between them and the user and before re-encrypting it to the origin server.
Secondly, CloudFlare are not doing any validation of the server's certificate with the Full SSL (non-strict) option. This means that it's not just about domain matching: none of the cert attributes: issuer, time range et al are checked.
Hence, someone can do a Man-in-the-middle attack between CloudFlare and you.
So, I wouldn't say it's very safe or secure, but it really depends on the type of data passing on your HTTPs channel.
It might be worth considering HTTP 301 redirect from https://domainB.com to https://userX.domainA.com rather than going for CNAME records, and using CloudFlare's Full (strict) SSL, if you're strongly concerned about your users' data.
We are going to need to start supporting multiple subdomains soon (de. fr. etc) so will need to change to a wildcard certificate. This is also good timing with the heartbleed bug.
To change to a wildcard cert I will need to create a new CSR, then when I use this new certificate I am worried that users will be shown warnings in there browsers.
Is there a way to avoid this or have I misunderstood the problem?
No, there will be no error if you turn your domain validated SSL certificate to WildCard SSL certificate, however you need to adjust domain name with new CSR such as for the WildCard SSL certificate, you need to use domain name in the format *.domainname.com
Wish you good luck! Cheers!