Securing api subdomain with single certificate - ssl

I have secured my www.domain.com, but I also want to secure the api.domain.com subdomain
How is this possible with a single letsencrypt domain?
Im running
Dokku
DigitalOcean

Let's Encrypt certificates are SAN certificates. It means you can bundle more than one domain/hostname in the same certificate.
The correct procedure depends on what tool/client you used to issue the certificate. Simply configure it with the domains you want.
Two important notes: the number of domains/hostnames is currently limited to 100. Moreover, while in public beta, Let's Encrypt limits the issuance to 5 certificates per domain. Therefore, if you reissue a certificate and/or issue a new one with multiple domains, you'll get closer to the limit.
Just beware of that. Be sure to read the rate-limit section here.

Related

Geting SSL certificates for many CNAME's?

Here is my situation:
I own and control coolwebsite.com
Many websites have a CNAME entry pointing to coolwebsite.com
For example, lamewebsite.com CNAME's a.lamewebsite.com to coolwebsite.com
There are about 50 of these other websites that point to mine, none of which I can control easily
How can I get an SSL certificate that will work with these CNAME's?
There are about 50 of these other websites that point to mine, none of which I can control easily
If you have no control over these web sites or their DNS settings than you should not be able to get a certificate for these. If this would be possible than it would be a serious security issue.
This appears to be a shared hosting kind of setup where you host the websites for clients and allow them to point their own domains to your server and use SNI or host header to serve a correct website based on domain used in the request.
More information like is above correct, where you're getting your TLS certs from, do you want to use single cert to cover everything or a cert per domain would be useful, but in general you can get a certificate with multiple Subject Alternative Names for different domain names/sites.
E.g. if you're using Let's Encrypt, with Domain Validation, you don't need control over domain's DNS, only over content served from that domain. And if people point their aliases (CNAMEs) to your web server then you already have it.

Understanding SSL: Self-signed vs Certified

I'm having a bit of trouble understanding a bit about SSL, namely self-signed vs certified.
First, is my assumption that a self-signed certificate will still prompt the common browser warning message?
Second, data from a https domain doesn't transfer to a http domain, right? So if I had my site at domain.com, and my api at api.domain.com, I would need two certs, and have both of them setup for https?
Last, I noticed there are free SSL certs at sites like StartSSL. This feels fishy, given it can easily cost $100 for a cert at other sites. Am I wrong in being concerned?
Using a self-signed certificate will cause browser warnings. Your assumption is correct.
It depends; some browsers may warn when this occurs. But you absolutely should serve all of your services on HTTPS, so that clients can authenticate your site(s) and so that the connection is private.
It is possible to support multiple domains on a single certificate, via the Subject Alternative Name (SAN, subjectAltName) X.509 certificate extension. You could also use separate certificates.
StartSSL is trusted by all browsers; their certificates will be accepted and there is nothing "fishy" about them. You could use StartSSL's free offering to obtain two certificates - one for each domain.
If you want a single certificate for multiple domains via the SAN extension, you will have to find a product that supports that, and it will probably not be free. The Let's Encrypt initiative is working to
change the landscape in this regard, but they have not yet launched.

Understanding ssl certificates

I am having a bit of trouble understanding how many ssl certificates I should get under specific conditions:
I have two pages the user is supposed to use (index and main) and all other scripts users don't access in the front end (e.g. uploadFile.php).
I have socket.io implemented in port x which I want to run over https protocol.
How many ssl certificates should I get under these conditions to assure secure data traffic? (is the data from all other php scripts still secure if index and main have ssl?)
SSL cert is issued for a specific DNS name. So if you run your PHP and Socket.io applications on the same domain, one cert is surely enough to secure both.
If you run your app on two different domains, you need to (a) use two separate regular certificates, or (b) have one SAN certificate (it secures multiple DNS names).
Also there is a wildcard certificate, it secures all direct subdomains of specified domain (*.some-site.com). It can be combined with SAN feature, so it can secure base domain some-site.com and direct subdomains as well.
IF your website is accessed via different website on https , then your website and the website through which its accessed needs to have their separate SSL certificate.
If your website does not have an ssl certificate , the connection will be dropped when your website link is accessed via other website.

Does enabling SSL require more than just turning it on?

I run an nginx-powered application and I recently turned my attention to using it over https. This is the module in nginx that does this: http://wiki.nginx.org/HttpSslModule
However, I'm somewhat unclear about what is actually required to run a site over https.
What else is there to do to serve my site over ssl? What is the role of the certificate, and is it a requirement that I purchase it from somewhere?
You need a certificate to prove to your user that the server they're connected to is indeed the one intended (and not a MITM attacker).
If your server is to be used by a limited number of users to whom you could give a certificate explicitly, you could use a self-signed certificate or create your own certification authority (CA).
Otherwise, if you want your certificate to be recognised by most browsers, you'll need to get one from a commercial CA.
You should find more details in this answer. You may also be interested in this.

Single Site w/ shared SSL Certs on Azure

We would like to setup an application on Windows Azure at abc.cloudapp.net which would have a CNAME record for www.mydomain.com pointing to it and then allow clients to do the same. Our application would then look at the requested URL and then pull out relevant data based on the requested domain (abc.theirdomain.com or www.theirotherdomain.com).
Our initial tests show that this should work, however the problem lies in that we need the site to be secure. So we'd like clients to be able to setup shared SSL certs with us that we would upload to our Azure subscription that then allowed them to create a CNAME record (abc.theirdomain.com or www.theirotherdomain.com) that points to either www.mydomain.com or abc.cloudapp.net.
Is this possible?
Edit: I'm not sure if this is the same question as Azure web role - Multiple ssl certs pointing to a single endpoint.
We've used a multi-domain certificate in this situation - see http://www.comodo.com/business-security/digital-certificates/multi-domain-ssl.php for details. This will work for up to 100 different top-level domains.
The problem with a multi-domain certificate is that it is more expensive than a "normal" certificate and that every time you add a new domain, you will have to deploy a new package with the updated certificate.
On the other hand, you could have multiple SSL certificates (one for each domain) and then the answer you seek is here Azure web role - Multiple ssl certs pointing to a single endpoint.
No, I don't think your setup would be possible with a single SSL cert. In general, SSL certs are tied to the hostname (e.g. foo.domain.com and foo.domain2.com need different certs). However, you can purchase a wildcard SSL cert that will help if you use the same root domain, but different subdomains (e.g. foo.domain.com and foo2.domain.com can share a wildcard cert).
So, in your case, since you are allowing different root domains, then you need a different SSL cert for each. If instead you choose to allow different sub-domains on same root domain, you can get away with the wildcard cert.