You are here
Self signed and trusted SSL certificates
Important note: Please note that current appliances include support for getting free Let's Encrypt SSL certificates. Please see the Let's Encrypt docs within the new Confconsole doc pages for full details.
Keeping it simple, HTTPS is a combination of the HTTP and SSL/TLS protocols, which provides encryption while authenticating the server. The main idea is to create a secure channel over an insecure network, ensuring "reasonable" protection from eavesdroppers and man-in-the-middle attacks.
HTTPS assumes that special CA (Certificate Authority) certificates are pre-installed in web browsers. If your SSL certificate is not signed by one of these CA's, the browser will display a warning:
TurnKey appliances generate self signed certificates on first boot to provide an encrypted traffic channel, but because the certificates are not signed by a trusted CA, the warning is displayed. In most cases, this is acceptable. If it's not, go get a signed certificate.
Authoritatively signed certificates
Cost
Authoritatively signed certificates can be costly, for example, Verisign (the most well known CA) charges $1,499 per year for their recommended certificate. There are cheap alternatives (I recently purchased a certificate from Go Daddy for $12.99) as well as a couple of free providers.
Generate key and CSR
First up is to create a certificate key and a certificate signing request (CSR). This can be done with OpenSSL.
apt-get update apt-get install openssl # replace bold type with your info openssl req -new -newkey rsa:2048 -nodes -out www_example_com.csr -keyout www_example_com.key -subj "/C=US/ST=Arizona/L=Scottsdale/O=Example Company Inc./CN=www.example.com"
Submit the CSR
The above will generate two files, www_example_com.key and www_example.com.csr.
Once you have signed up for an authoritatively signed certificate, you will be requested to upload the CSR file or its contents.
Verify the request
The signing authority will need to verify the validity of the request and that it was submitted by the entity to which the domain in the request is registered, usually done by contacting the administrative contact for the domain.
Further steps may be required when requesting an Extended Validation (EV) certificate, which color the address bar green in recent browsers.
Download signed certificate
After validation, your signed certificate (crt) will be available for download. Most likely your signing authority will include an intermediate CA certificate bundle (trust chain).
Note: you should make a backup of all SSL related files.
Generate PEM and placement
Generate the pem from the key and crt
cat www_example_com.key www.example.com.crt > cert.pem
Place the generated pem and intermediate bundle (eg. bundle.crt) in /etc/ssl/certs/, and make them read-only to root.
chown root:root *.pem *.crt chmod 400 *pem *.crt
Update configuration, enable SSL and reload webserver
Apache configuration
<VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/ssl/certs/cert.pem SSLCertificateChainFile /etc/ssl/certs/bundle.crt </VirtualHost>
a2enmod ssl
/etc/init.d/apache2 force-reload
Lighttpd configuration
/etc/lighttpd/conf-available/10-ssl.conf $SERVER["socket"] == "0.0.0.0:443" { ssl.engine = "enable" ssl.pemfile = "/etc/ssl/certs/cert.pem" ssl.ca-file = "/etc/ssl/certs/bundle.crt" }
lighty-enable-mod ssl
/etc/init.d/lighttpd force-reload
Do you use an authoritatively signed certificate? Is self-signed sufficient? Leave a comment!
Comments
StartSSL free certs
If you are using an SSL certificate for testing, http://www.startssl.org/ offers free certificates that are authorititavely signed. You have to pay for certs that you use for e-commerce and secure transactions, but for testing, their free certs work very well.
Free certificate for open source projects
I assume the GoDaddy cert
I assume the GoDaddy cert will expire in 1 year and you have to pay for renewal or get a different cert.
I have used the StartSsl certs for non open-source projects so that is an advantage there.
Did you restart the webserver?
Try restarting the webserver so changes take effect.
Which config file?
If I already have a site up and running using the Turnkey LAMP stack, which Apache config file should I be editing?
If I edit the default one won't those changes only show on new virtual hosts not existing ones?
My 2 Step and 2 Bits on SSL Certs
To answer your question at the end: Do you use an authoritatively signed certificate? Is self-signed sufficient?
I tend to use the SSL Generated Certs for Webmin, WebShell and PHPMyAdmin. If I need SSL for a Public site I have been finding $10 certs recently on Comodo and getting irritated when they try to renew for $50.. I think I found a good alternative that seems more "ong term in it price offering just now at:
www.namecheap.com
They have good pricing on Domain Registrations as well though I like Tucows for that.
1 and 2 year SSL certs for less than $10 a year (even 3 years if you want to avoid the hassle).
That was the Hard Work. The next part was just refresh/repeat from previous cert installs.
Run the process outlined in the great blog post above to generate the CSR (Certificate Signing Request).. For me this is easiest in Webmin because I can Copy Paste then edit before submitting look in your root directory to find it, then move it with the the Certs you are Generating to etc/ssl/private (or a folder of your choice).
Generally you need to take 2 Certs (the primary cert and the intermediate cert and copy them into new files --
In Apache - Go to Edit Directives under your 443 Port. The following is my general format calling out .cert (or .crt) .key and intermediate.cert :
In fact I am here posting because I needed to get the script again to generate a CSR and it was about as easy a SSL install as I have done... Templates are the key... and avoid Comodo's Bait and Switch. GeoTrust seems, to me anyway, the more reputable SSL provider.
Thanks for posting back with your info
I'm sure others will find your discovery useful.
self signed ssl certificate warning - not going
Hi all,
Can any please help me with the configuration of an ssl certificate loaded on a virtual server.
I made the below configurations however the virtual server keeps on providing the selfsigned certificate warning from turnkey.
Would appreciate if some Linux expert(s) can help me with this on priority. Thanks in advance...
Lighttpd configuration
JN
How do I configure this for Port 12321 or some other port?
I purchased a UCC certificate and have it running on three domains on a LAMP server on port 443. That part works fine. One of the server names corresponds to the Webmin installation I have on the machine. How do I configure port 12321 (or 8080 in my case, I changed it) to use the SSL certificate? I tried adding:
to a site-available .conf file, but I still get the scary error message. Any suggestions?
There is normally more than pasting a certificate and key in...
I have never used Webmin to fill in cert and key, specifically, so I don't know the situation specifically you have, but my feeling is that you don't need a customized cert for webmin or webshell. You are the only one normally logging in and you can always accept the self-signed or built in cert.
Where you want a custom cert is on the outward pointing system/web site etc. Above I noted how I normally install a cert in the post titled "My 2 Step and 2 Bits on SSL Certs" . Specifically there you need to get your key, cert, and trusted authority certs all be installed. I do that through Webmin, but functionally as a series of "text edits" in the APACHE SERVER SETUP in Webmin - or directly in Webshell.
When you do this the cert will move forward with TKLBAM backups and restores and you will only have to update the setup when your certificate (or certificates) expire.
Hope this helps - again, see the post above titled. You are Setting these settings within APACHE in Webmin normally as opposed to the whole install.
My 2 Step and 2 Bits on SSL Certs
TBH I have no idea...
But it's possible I guess. Have you tried following the tutorial to see if it works?
I guess another good option might be to ask Apple themselves (or on Apple support forums or something?) and if so how you might go about it...
Bad forum etiquette - totally off topic
Initially I thought your thread hijack was somewhat legitimate (I thought you were referring to using an Apple provided cert on a TurnKey appliance). But now we're totally off topic talking about OSX servers and CentOS. These are the TurnKey Linux (Debian based software appliances) forums. Please take your discussion somewhere more appropriate. At least have the courtesy to start your own thread rather than hijacking someone else's and taking it completely off topic...
Perhaps ask on the CentOS forums...?
On the "development" Jessie Builds (how to apply to Webmin-Shell
I've got certs in all parts of Apache but I am not finding how Webmin and Webshell are controlled.
Thought it might be "lightly" below but nothing in the directory as described.
Please inform.
thanks,
What about Webmin/shell in a box?
The steps above have worked great for me (I get the green lock in my browser when I visit standard HTTPS protocol pages from the server). In the end I did not keep the name cert.pem (as the above poster suggested) and I think this is actually causing other issues.
When I go to the webmin interface at port 12321 (or shell-in-a-box at 12320) this does not get the right certificate. Chrome reports that it is still receiving the old self-signed certificate.
I have dug as much as I can and I cannot figure out how webmin is even intercepting that port! Apache does not appear to be listening on it or doing any sort of HTTP proxy and the /etc/webmin/miniserv.conf file is listening on port 10000 not 12321. Shell-in-a-box is much the same (I just can't figure out where the server is that serves it and it doesn't seem to be apache).
Can anyone point me to where I can get webmin to use the proper certificate? I know nothing about webmin really so I'm not even sure where I should look to configure it and what I thought was the obvious place (/etc/webmin/miniserv.conf) doesn't look right.
In v14.0 Webmin & Webshell are behind stunnel
Ahhhh! Perfect!
A short trip over to /etc/stunnel/stunnel.conf and there's a very obvious line that needs to be updated:
Switch that to your properly signed cert and restart stunnel4 and bingo, it works!
No Joy - Feeling Dumb
Well - I hate to admit that I have spent way to many hours trying to understand some of the nuances of this SSL thread - and still can't be successfull getting my certs to install and function.
I have no issues conducting any of the steps - it's just that they universally leave me with an error 500 internal server error when I'm finished.
I'm not clear on if I should be using the .pem or the .crt, but both methods fail equally and identically. Nothing I have done so far has any impact on the cert for webmin.
I like "secure out of the box" - but a self signed cert has limited play in the real world. And I really want to use the turnkey appliance in the real world.
Because I know there are LOTS of folks in this forum way smarter than me - maybe someone could rewrite this post with steps that are known to work - without any of the additional conversations and steps that dont really work.
I'm guessing that the very same directions would be appliable to all the turnkey distributions, which means writing this up will help folks use ALL the various appliances turnkey has built. Seems like it would be a good investment of time; I can't be (I HOPE) the only person whos been struggling and unseccessfull with certificates.
Come on guys - can anyone step up to this? Heck - I'll even write it up for the forums here nice a pretty if I can just figure out how to make it work. :)
Lost and forlorn in Turnkey certificate land -
TonyS
TurnKey Confconsole supports getting Let's Encrypt certs
Since v14.2 TurnKey's Confconsole (commandline UI configuration tool) supports getting Let's Encrypt certificates OOTB.
They are free and work well, so what's not to like! :)
As I just posted above...
Since v14.2 TurnKey's Confconsole (commandline UI configuration tool) supports getting Let's Encrypt certificates OOTB.
Here’s the mail I got
Here’s the mail I got recently for my problem
Disable QUIC Protocol
in URL write "chrome://flags/#enable-quic Protocol" and hit Enter,
if will be selected as Default, now click on that drop-down and select Disabled,
now click on Relaunch in bottom.
2) Update the system Time
3) Disable unknown or unused extensions
4) Check if there is restrictions on Firewall or not.
If you error is still not solved, or getting other SSL error please visit <ERR_SSL_PROTOCOL_ERROR – Fix by deskdecode>
Where are the SSL certs now?
Yep, this blog post has recently turned 12!
This blog post has recently turned 12, so yes, it's really old (and now out of date)!
Exactly what you'll need to do will depend on how you have set everything up, including the TurnKey Let's encrypt integration.
Just to step back a little, let me share how I'd probably set this up if it were me. Personally, I'd terminate the SSL/TLS (i.e. HTTPS) connection at your reverse proxy. That way the Let's Encrypt certificates are created, stored and hosted on the reverse proxy (and don't need to go anywhere).
Then if all the backend resources are secured and you trust your network security you can just use plan http connections to your backend services. Having said that, IMO that sort of config is only suitable for small hobby type projects. And it's only an option where the traffic and reverse proxy does not leave your network.
If you need (or want) things more locked down than that, then you can use self signed certs for your backend servers. Here you again have multiple pathways. Either generate new self signed certs (with appropriate CA files too) then load those CAs (or the cert is using Nginx) onto your reverse proxy (so it can check the validity of the self signed certs). Alternatively, you could just configure your reverse proxy to ignore the (technically invalid) self signed certs. Using unverified self signed certs is better than just using plain http, but not as good as verified certs (even if self signed).
Exactly what changes you need to do to achieve that will depend on what server you are using for your reverse proxy. If it's Nginx, it's pretty easy. To disable checking the SSL/TLS cert (after proxy_pass and other proxy config you may have):
To supply a CA file to check against:
Or to provide the self-signed cert itself:
For further details of related config on Nginx, please see the Nginx docs.
It's also possible if you're using Apache as a reverse proxy, although I'm not as familiar with that, so can't give quite as explicit info. The theory is the same though, so I imagine that the similar directives are things like SSLProxyVerify, SSLProxyCACertificateFile. Hopefully you can work it out from there (if that's the way you want to go). Apache doc pages that might be worth further perusal would be for mod_proxy and mod_ssl.
Alternatively, if you wish to persevere with your current config (which is possibly the quickest easiest way to go from where you are currently - it just has more moving parts, so more that could go wrong), then that should be relatively straight forward.
By default the Confconsole Let's Encrypt integration creates just one certificate, which includes all the domains that you configured it to use. That will write the combined cert to /etc/ssl/private/cert.pem & /etc/ssl/private/cert.key. That single cert (and key if required; although by default the cert.pem file also includes the key(s)) will then be valid for any/all domains that you configured it for. If you've configured it to just create that single cert, then you can copy that to all of your guests and it should "just work". If you haven't already got it configured like that, you could reconfigure it like that if you wish.
If you are using Dehydrated to create multiple certs (as it sounds like you are) then as you seem to be aware, the certs are written to /var/lib/dehydrated/certs/DOMAIN/. In amongst the weirdly named files, there should be symlinks (named something more obvious) pointing to the latest files. So use those symlink(s) rather than the actual files themselves (or read the symlink to get the current real file - e.g. using readlink).
No doubt there are probably other alternative ways you could configure things (and still get them to work) but that's probably enough to be going on with...
Pages
Add new comment