I inherited this server set up with my job and I'm trying to make sense of it...
Our domain's NS records point to Cloudflare (xxx.xxx.xxx.163). We have a valid cert with them.
Everything looks fine from the browser end and with online cert checkers for this cert.
On Cloudflare, the DNS 'A' record points to 3dCart.com (xxx.xxx.xxx.212). Here's where our web content resides.
But if I do a DNS lookup, I get the Cloudflare IP (xxx.xxx.xxx.163).
So it looks like the 3dCart server is totally transparent.
We currenlty have a second SSL with the 3dCart's ip (xxx.xxx.xxx.212).
Do we need to have this second cert?
I don't see how it can ever be accessed
Yes, you should have that origin certificate. Cloudflare accesses your origin site securely using that Origin Certificate. However, the Origin Certificate doesn't need to chain to a public root. You can let CloudFlare issue a free certificate from its private root CA or use a self signed certificate for your Origin certificate.
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 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.
I have just installed a wildcard ssl certificate on a custom domain, this is working fine for any subdomain of *.example.com. I can verify that the correct ssl certificate is being issued.
However the problem is with www. which is issuing the Bluemix certificate not my own certificate.
In the browser i am getting "Your connection is not private"
This server could not prove that it is www.example.com; its security certificate is from *.eu-gb.mybluemix.net. This may be caused by a misconfiguration or an attacker intercepting your connection.
I am guessing that the problem is with Bluemix, how can i get Bluemix to serve up my certificate for www, baring in mind that it is serving up my certificate for other subdomains.
All help will be greatly recieved
I have fixed this issue, the problem was with the DNS setup.
The key piece of information for me, was that my dns was point to 2 IP's of Bluemix 5.10.124.142, and 5.10.124.141, therefore only serving up my certificate on one, and the Bluemix default certificate on the other
From googling how to add a custom domain, i added a CNAME record to point to *****.eu-gb.mybluemix.net and an A record to 5.10.124.142
This is wrong, i need to change my CNAME record to be my actual domain now.
I would like to generate an SSL Certificate Signing Request (CSR) for the procurement and installation of an SSL certificate.
My question surrounds what we should enter for the FQDN given our specific situation
We will be hosting a domain name 'www.foo.com' within our server.
This domain will be accessed via a different domain 'www.bar.com' which will be CNAMEd to our hosted domain 'www.foo.com'
We want the client to see that the domain 'www.bar.com' has a valid SSL certificate.
So my question is, when we generate the CSR do we need to enter 'www.foo.com.' or 'www.bar.com.' as the FQDN for hostname in the CSR?
Edit: It is not intended that the domain name www.foo.com will ever be used to access the website.
Looking at this answer https://serverfault.com/questions/494654/which-fqdn-hostname-to-use-for-ssl-certificate-signing-request-when-using-a-cna it looks like in our CSR we should be using 'www.bar.com.' but confirmation from a suitably qualified person would be appreciated!
www.bar.com
Whatever FQDN the client requests in the browser should be in the subject of the certificate - no matter what happens in "the background", be that in terms of DNS resolution, backend proxying etc.
As long as the browser thinks it's talking to www.bar.com, the browser will also expect www.bar.com to be in the certificate
I have a site that has subdomains for each user and a wildcard SSL Cert
https://user1.mysite.com
https://user2.mysite.com
The question is can someone set a cname record such as user1.theirsite.com -> user1.mysite.com and have it still use https?
Will it work if they install a SSL Cert on their server to secure the connection?
Thanks
The best way for this to work is if they arrange with you to have your SSL certificate include their "alias" as a Subject Alternate Name extension in your X.509 certificate.
This is the approach used by some CDNs when they host https sites for clients - they put all of the known site names that are hosted on one server in one large SSL certificate, and then the clients use CNAMEs to point their domain at the right CDN server.
The host name and certificate verification (and in fact, checking that SSL is used at all) are solely the responsibility of the client.
The host name verification will be done by the client, as specified in RFC 2818, based on the host name they request in their URL. Whether the host name DNS resolution is based on a CNAME entry or anything else is irrelevant.
If users are typing https://user1.theirsite.com/ in their browser, the certificate on the target site should be valid for user1.theirsite.com.
If they have their own server for user1.theirsite.com, different to user1.mysite.com, a DNS CNAME entry wouldn't make sense. Assuming the two hosts are effectively distinct, they could have their own valid certificate for user1.theirsite.com and make a redirection to https://user1.theirsite.com/. The redirection would also be visible in the address bar.
If you really wanted to have a CNAME from user1.theirsite.com to user1.mysite.com, they might be able to give you their certificate and private key so that you host it on your site too, using Server Name Indication (assuming same port, and of course same IP address since you're using a CNAME). This would work for clients that support SNI. There would however be a certain risk to them in giving you their private keys (which isn't generally recommended).
The following is set up and working:
DNS entry for a.corp.com -> CNAME b.corp2.com -> A 1.2.3.4
The haproxy at 1.2.3.4 will serve up the cert for a.corp.com and the site loads fine from a webserver backend.
So, on your server you will need user1.theirsite.com cert and it will work.