My site uses Cloudflare CDN. So in this case I have to have 2 encryption, one configured in Cloudflare and one in my server?
If yes, then can these encryptions use the same digital certificate or do they have to be different certificates?
My site is in Wordpress Multisite, and I have subdomain set up. For this case, do I have to set up an SSL certificate for each different subdomain (mysite.com, sub1.mysite.com, sub2.mysite.co, …)?
Is the Let’s Encrytp certificate free for lifetime (unlimited) or is it for a trial period and then will it be paid? Do I have to renew the Let’s Encrypt certificate periodically, for example, all year round renew the certificate?
And how many bits (1024 or 20148) have the encryption of Let’s Encrypt?
Others can address your Cloudflare questions, but I can answer this: yes, Let's Encrypt is really, truly, free.
Yes, the Let's Encrypt certificate is only good for 90 days, after which (or, ideally, before which) it must be renewed. The use case intended is that the certificate will be automatically obtained and renewed by software, so it won't require any manual intervention on your part.
The actual encryption is up to your server setup, but the default key length for Let's Encrypt is 4096 bits.
CloudFlare has its own “certificate authority”. Of course nowhere trusted in browsers and other clients, but you can use it for the encryption between your server and CF. See also Introducing CloudFlare Origin CA.
Hello danb35, after 90 days, I do not need to do anything for the renewal of the certificate? Is everything done automatically? But for this I need to configure some software that will do this automatic renewal?
Hello Osiris, you say that Cloudflare’s own certificate is not trusted and recognized by all browsers? If so then you’d better not use it.
No, browsers/clients will connect to CloudFlare. So they see CloudFlare's certificate. Only the communication between CloudFlare and your server uses the CF certificate. Like I said, see the blog post from CF I posted earlier.
Of course, if you disable CF's services and let clients/browsers connect directly to your server, you'll need another certificate.
There is no server-side default (the client requesting a certificate has to generate a specific keypair to which he certificate should refer), but the default in the Certbot client is 2048 bits. I believe Let's Encrypt currently allows RSA subject public keys with 2048, 3072, or 4096-bit moduli (and not any other size).
People often don't realize that in modern practice, this key is typically only used for authenticating your server when a client sets up a TLS session; the actual keys that are used to protect the connection once it's started are different and use a wide range of different cryptography, much of which you can influence with your own server settings.
This means that the size of the public key is only one of many things relevant to the security of encrypted connections to your server, and it's relevant only in a very narrow way.
Supporting the best available cryptography for the actual TLS session is an important reason to keep both client and server software up to date, so that they're not stuck trying to use obsolete cryptographic mechanisms to talk to each other.
If you get the certificate yourself using some kind of client software application, you will probably also have to configure the application to renew the certificate every 90 days (or, ideally, more often). For example, people running Certbot on their own server usually run some form of certbot renew from cron in order to check periodically whether renewals are necessary (and perform the renewal if it is necessary). If you use some kind of service that handles obtaining the certificate for you, that service will likely also perform the renewal for you.
Sure, though in this case the attacker would need to be on-path and able to do a real-time active attack in order to make use of an attack against the private key at the start of a given session, which is a much stronger limitation than problems with other parts of the crypto (like attacks that enable recovery of the session key, which would allow passive retrospective decryption of the whole session contents).
Yes, very true. Most important is a safe cipher. Interesting discussion though, to ECC or not to ECC, with quantum computing on its way and all And if you like aluminium hats, perhaps a discussion about the NIST ECC curves, being NSA backdoored of course!
In short … I need to set up an SSL certificate on my CDN (Cloudflare) to encrypt the data transmissions between the CDN and the server. And then I have to set up an SSL certificate on my server to encrypt the data transmissions between my server and the user’s browser. Right?
If so, then the SSL certificate used between CDN and Server is the same as the SSL certificate between Server and User’s browser, ie the same public and private key?
If I can use different certicados then could I use different CA?
For example, between Cloudflare and Server I use the CA of Cloudflare itself, and between the Server and Navigator I use the CA’s Let’s Encrypt. Can this be done without any problem?
How long does it take, on average, to set up an SSL certificate throughout the site?
And for sites in Wordpress that have subdomains, should each of the subdomains be configured a different SSL certificate? Since all the sites in a WP multisite network use the same database, then it would not be possible to configure a single SSL certificate and thus encrypt all sites (mysite.com, sub1.mysite.com, sub2.mysite.com, Sub3.mysite.com, …) all at once?
[quote="rodrigocs, post:11, topic:26598"]
I need to set up an SSL certificate on my CDN (Cloudflare) to encrypt the data transmissions between the CDN and the server. [/quote]
Correct.
Nope. The users browser will connect to your CDN (CloudFlare). Not your server.
CloudFlare has its own certificates with their own public/private keypair. They have many, many FQDN's in one certificate for all the clients they provide for, including yours. So no, you won't get their keys
"Navigator" = users browser? If so: no. See above. The users browser will connect to CloudFlare, not your server, when using CloudFlare's CDN services.
Is encryption done in a domain (eg mysite.com) also encrypts subdomains (eg sub1.mysite.com, sub2.mysite, …)? That is, if I have a site with multiple subdomains, do I need to set up an SSL certificate for the top domain and then for each subdomain?
Each hostname that you want to access securely needs to be certified. So, if you want secure communications with mysite.com, sub1.mysite.com, and sub2.mysite.com, you’ll need one or more certificates covering all those hostnames. You can include them all in a single cert, get one cert for each host name, or any other arrangement you choose (e.g., mysite.com as one certificate, sub1 and sub2 combined in a second certificate).
If in the case I set up a single certificate for all sites, then in the user’s browser would it show that encryption is being done in the main mysite.com domain, even if that user was accessing eg sub2.mysite.com?
Regarding the encryption of my CDN (Cloudflare) and my Server … if the user’s browser connects to Cloudflare and Cloudflare connects to my Server, this is 2 connections that need to be encrypted. So I have to configure 2 different SSL certificates, one for each connection (Browser> Clodflare and Cloudflare> Server), or is it just a single SSL certificate for the 2 connections?
If in the case I set up a single certificate for all sites, then in the user’s browser would it show that encryption is being done in the main mysite.com domain, even if that user was accessing eg sub2.mysite.com?
It doesn’t really matter but if they’re all parts of the same site and on the same server then 1 cert for all is good.
With Cloudflare on a free or pro plan the connection between the public and Cloudflare uses a cert managed by them and shared with other customers. Your LE cert will only be used for the connection from Cloudflare to your server. As for what shows in the browser, it depends on where the user is looking, clicking the padlock icon will show the subdomain they’re on, while the cert details will show a subdomain of cloudflaressl.com.
Even using a single certificate for all sites (main domain and subdomains), would I have to make settings on all VHots (from the main domain and subdomains), or is the configuration only done on the main domain’s VHot?
Do I need a tutorial teaching the certificate configuration on a Wordpress site that uses subdomains?
You just need to "certify" your server. And only CloudFlare will connect to your server, as all the browsers will connect to CloudFlare, not to your server. If you've enabled the CDN-features of CloudFlare of course. If so, CloudFlare will take care of the certification on their end.
I’m having mismatched information. My server (DigitalOcean) told me that it is necessary to have a different certificate for each of the connections, that is:
a certificate between Browser and Cloudflare
a certificate between Cloudflare and Server
Now for the subdomains, they passed me the recommended one would be a different certificate for each site, but a single wildcard certificate could be used if I used a wildcard subdomain (* .mysite.com). This is correct?
In my case, I have not activated wildcard subdomains in Cloudflare, and so I’m creating the subdomains manually. With this I have to have a different certificate for each subdomain, ie a single certificate for all sites is only possible for wildcard subdomains, correct?
A single certificate for all sites is possible using a non-wildcard, even if the sites are within different domains. A Let’s Encrypt certificate can cover up to 100 different names in the same certificate.
The X.509 certificate mechanism that allows this is called Subject Alternative Name (or SAN) and has been supported in TLS clients for a long time (unlike a different mechanism called Server Name Indication which allows the client to state at the time of connection which server name it wants to talk to, which can then allow a potentially unlimited number of sites with a potentially unlimited number of certificates to share a single IP address).
And if you like aluminium hats, perhaps a discussion about the NIST ECC curves, being NSA backdoored of course! 
