Tutorial
How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 16.04
Not using Ubuntu 16.04?Choose a different version or distribution.
Introduction
TLS, or transport layer security, and its predecessor SSL, which stands for secure sockets layer, are web protocols used to wrap normal traffic in a protected, encrypted wrapper.
Using this technology, servers can send traffic safely between the server and clients without the possibility of the messages being intercepted by outside parties. The certificate system also assists users in verifying the identity of the sites that they are connecting with.
In this guide, you will learn how to set up a self-signed SSL certificate for use with an Apache web server on an Ubuntu 16.04 server.
Note: A self-signed certificate will encrypt communication between your server and any clients. However, because it is not signed by any of the trusted certificate authorities included with web browsers and operating systems, users cannot use the certificate to validate the identity of your server automatically. As a result, your users will see a security error when visiting your site.
Because of this limitation, self-signed certificates are not appropriate for a production environment serving the public. They are typically used for testing, or for securing non-critical services used by a single user or a small group of users that can establish trust in the certificate’s validity through alternate communication channels.
For a more production-ready certificate solution, check out Let’s Encrypt, a free certificate authority. You can learn how to download and configure a Let’s Encrypt certificate in our How To Secure Apache with Let’s Encrypt on Ubuntu 16.04 tutorial.
Prerequisites
Before starting this tutorial, you’ll need the following:
-
Access to a Ubuntu 16.04 server with a non-root, sudo-enabled user. Our Initial Server Setup with Ubuntu 16.04 guide can show you how to create this account.
-
You will also need to have Apache installed. You can install Apache using
apt. First, update the local package index to reflect the latest upstream changes:Then, install the
apache2package:And finally, if you have a
ufwfirewall set up, open up thehttpandhttpsports:
After these steps are complete, be sure you are logged in as your non-root user and continue with the tutorial.
Step 1 — Enabling mod_ssl
Before we can use any SSL certificates, we first have to enable mod_ssl, an Apache module that provides support for SSL encryption.
Enable mod_ssl with the a2enmod command:
Restart Apache to activate the module:
The mod_ssl module is now enabled and ready for use.
Step 2 — Create the SSL Certificate
Now that Apache is ready to use encryption, we can move on to generating a new SSL certificate. The certificate will store some basic information about your site, and will be accompanied by a key file that allows the server to securely handle encrypted data.
We can create the SSL key and certificate files with the openssl command:
After you enter the command, you will be taken to a prompt where you can enter information about your website. Before we go over that, let’s take a look at what is happening in the command we are issuing:
- openssl: This is the basic command line tool for creating and managing OpenSSL certificates, keys, and other files.
- req: This subcommand specifies that we want to use X.509 certificate signing request (CSR) management. The “X.509” is a public key infrastructure standard that SSL and TLS adheres to for its key and certificate management. We want to create a new X.509 cert, so we are using this subcommand.
- -x509: This further modifies the previous subcommand by telling the utility that we want to make a self-signed certificate instead of generating a certificate signing request, as would normally happen.
- -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Apache to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening because we would have to enter it after every restart.
- -days 365: This option sets the length of time that the certificate will be considered valid. We set it for one year here.
- -newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The
rsa:2048portion tells it to make an RSA key that is 2048 bits long. - -keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
- -out: This tells OpenSSL where to place the certificate that we are creating.
As we stated above, these options will create both a key file and a certificate. We will be asked a few questions about our server in order to embed the information correctly in the certificate.
Fill out the prompts appropriately. The most important line is the one that requests the Common Name. You need to enter either the hostname you’ll use to access the server by, or the public IP of the server. It’s important that this field matches whatever you’ll put into your browser’s address bar to access the site, as a mismatch will cause more security errors.
The entirety of the prompts will look something like this:
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:Example
Locality Name (eg, city) [Default City]:Example
Organization Name (eg, company) [Default Company Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Example Dept
Common Name (eg, your name or your server's hostname) []:your_domain_or_ip
Email Address []:webmaster@example.com
Both of the files you created will be placed in the appropriate subdirectories of the /etc/ssl directory.
Step 3 — Configure Apache to Use SSL
Now that we have our self-signed certificate and key available, we need to update our Apache configuration to use them. On Ubuntu, you can place new Apache configuration files (they must end in .conf) into /etc/apache2/sites-available/and they will be loaded the next time the Apache process is reloaded or restarted.
For this tutorial we will create a new minimal configuration file. (If you already have an Apache <Virtualhost> set up and just need to add SSL to it, you will likely need to copy over the configuration lines that start with SSL, and switch the VirtualHost port from 80 to 443. We will take care of port 80 in the next step.)
Open a new file in the /etc/apache2/sites-available directory:
Paste in the following minimal VirtualHost configuration:
<VirtualHost *:443>
ServerName your_domain_or_ip
DocumentRoot /var/www/your_domain_or_ip
SSLEngine on
SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
</VirtualHost>
Be sure to update the ServerName line to however you intend to address your server. This can be a hostname, full domain name, or an IP address. Make sure whatever you choose matches the Common Name you chose when making the certificate.
The remaining lines specify a DocumentRoot directory to serve files from, and the SSL options needed to point Apache to our newly-created certificate and key.
Now let’s create our DocumentRoot and put an HTML file in it just for testing purposes:
Open a new index.html file with your text editor:
Paste the following into the blank file:
<h1>it worked!</h1>
This is not a full HTML file, of course, but browsers are lenient and it will be enough to verify our configuration.
Save and close the file
Next, we need to enable the configuration file with the a2ensite tool:
It will prompt you to restart Apache to activate the configuration, but first, let’s test for configuration errors:
If everything is successful, you will get a result that looks like this:
OutputAH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK
The first line is a message telling you that the ServerName directive is not set globally. If you want to get rid of that message, you can set ServerName to your server’s domain name or IP address in /etc/apache2/apache2.conf. This is optional as the message will do no harm.
If your output has Syntax OK in it, your configuration file has no syntax errors. We can safely reload Apache to implement our changes:
Now load your site in a browser, being sure to use https:// at the beginning.
You should see an error. This is normal for a self-signed certificate! The browser is warning you that it can’t verify the identity of the server, because our certificate is not signed by any of its known certificate authorities. For testing purposes and personal use this can be fine. You should be able to click through to advanced or more information and choose to proceed.
After you do so, your browser will load the it worked! message.
Note: if your browser doesn’t connect at all to the server, make sure your connection isn’t being blocked by a firewall. If you are using ufw, the following commands will open ports 80 and 443:
Next we will add another VirtualHost section to our configuration to serve plain HTTP requests and redirect them to HTTPS.
Step 4 — Redirecting HTTP to HTTPS
Currently, our configuration will only respond to HTTPS requests on port 443. It is good practice to also respond on port 80, even if you want to force all traffic to be encrypted. Let’s set up a VirtualHost to respond to these unencrypted requests and redirect them to HTTPS.
Open the same Apache configuration file we started in previous steps:
At the bottom, create another VirtualHost block to match requests on port 80. Use the ServerName directive to again match your domain name or IP address. Then, use Redirect to match any requests and send them to the SSL VirtualHost. Make sure to include the trailing slash:
<VirtualHost *:80>
ServerName your_domain_or_ip
Redirect / https://your_domain_or_ip/
</VirtualHost>
Save and close this file when you are finished, then test your configuration syntax again, and reload Apache:
You can test the new redirect functionality by visiting your site with plain http:// in front of the address. You should be redirected to https:// automatically.
Conclusion
You have now configured Apache to serve encrypted requests using a self-signed SSL certificate, and to redirect unencrypted HTTP requests to HTTPS.
If you are planning on using SSL for a public website, you should look into purchasing a domain name and using a widely supported certificate authority such as Let’s Encrypt.
For more information on using Let’s Encrypt with Apache, please read our How To Secure Apache with Let’s Encrypt on Ubuntu 16.04 tutorial.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
About the author(s)
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Become a contributor for community
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
DigitalOcean Documentation
Full documentation for every DigitalOcean product.
Resources for startups and SMBs
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
Get our newsletter
Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.
New accounts only. By submitting your email you agree to our Privacy Policy
The developer cloud
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Get started for free
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.
Great tutorial; lots of details & easy to follow. Probably should mention we can avoid using self-signed certs, and use Let’sEncrypt CA.
@TrevorLaneRay: Thanks for the feedback!
In case you missed it, there’s a note linking to our Let’s Encrypt guide in the introduction up top. This guide was created to supplement those procedures for times when a signed certificate might not be a good fit (like when testing, internal communications, or for things that Let’s Encrypt doesn’t currently support, like wildcard certificates). We’re definitely excited about Let’s Encrypt though! It makes things really straight forward!
Thanks again for the comment.
Ooh, totally missed that. :D Kudos on clearing up when self-signed certs are preferred. Completely forgot Let’sEncrypt doesn’t yet do wildcard certs.
Thanks for the “Let’sEncrypt” info!
I’ve used this on all of the Ubuntu servers I’ve deployed and in a custom installation script for an Ubuntu based ownCloud server.
The ownCloud server brought something to my attention: the ssl-params.conf file is never enabled. It does not show in conf-enabled after completing an install, and ownCloud complains about the max-age setting not being enabled.
How is the .conf file being accessed by Apache or the SSL mod to pull the settings for use?
I’ve taught myself Linux and bash scripting over the course of three months while developing that installation script (it automates nearly every aspect of a 20 page walk-through I wrote for configuring the server based on very high security standards), so I may be making a noob mistake.
@kevinruffus: Oh goodness, you’re completely right! That’s a bit embarrassing :). I’ll fix that up in just a minute. In the meantime, you can enable the config by typing:
You should see that the link has been added to the `conf-enabled directory:
Check to make sure there weren’t any syntax errors and then restart the service:
The SSL parameters should now be applied.
Thanks for the heads up! Let me know if you spot anything else.
I went through and figured that out, but thank you for getting back to me about it so I know I wasn’t just losing my mind.
For anyone who runs into trouble with ownCloud using this setup, ownCloud inserts it’s own settings for the nosniff and DENY options, so they may have to disable those in the ownCloud root directory .htaccess file. I’m playing with the settings on a testbed VM to see if that can be worked around.
Unless someone knows how to bypass the Header always set X-Frame-Options “DENY” and Header always set X-Content-Type-Options “nosniff” directives for a php based site, users hosting an instance of ownCloud will have to change Header always set X-Frame-Options to SAMEORIGIN and comment out those two lines in owncloud/.htaccess, as the initial settings cause a conflict and will throw errors in ownCloud, and an insane number of issues with mod_security.
After further digging, it seems it’s the “always” parts of the settings that cause problems. Removing always seems to set those options by default, but allowing sites to override, which ownCloud does. Since the ssl directives were trying to take precedence, ownCloud was having a fit, and screamed about bad files when altering the .htaccess file.
Sorry about the string of comments, I’m just plowing my way through learning all of this and figured someone else may run into the same issue.
If anyone is hosting ownCloud, the always needs to be left out on the x-frame-options and x-content-type-options lines.
Why am I getting the following error?
Same here!
Had to comment out (using #) both SSLSessionTickets and SSLOpenSSLConfCmd lines.
Could the author please give us some reason why is this happening and the security implications of taking those out?
Thanks!
@daramir: Hello! Please see my response to @Debiprasad. Let me know if that matches what you’re experiencing.
@Debiprasad If the
SSLSessionTicketsis throwing a configuration error, this may either be an indication that you are not using a high enough version of Apache.SSLSessionTicketswas introduced as part ofmod_sslin Apache 2.4.11, so it is available in Ubuntu 16.04, which ships with version 2.4.18. If you are running this on the wrong distribution, you’ll probably run into this error. You can check your version of apache by typing:On Ubuntu 16.04, this should give you something like this:
Hope that helps.
Thank you for this information @jellingwood ! That was actually the thing, I’m running Ubuntu 14.04.4 LTS and therefore
Kind of embarrasing to miss out this point! Thanks and I think it will help @Debiprasad and @Tayskeno as well.
Hello,
I am getting this kind of error : Could you help to identify the issue ?
I generally appreciate the clarity of your explanations; this is a definite +!
However, I would need to move one step beyond the " Redirect “/” “https://your_domain_or_IP”" line, which works perfectly from the Internet to my web server, but not from clients on the same LAN as the server.
Can I branch to something like "Redirect “/” “https://my_server_local_IP” by detecting the origin of the client IP or else?
Just Subscribed in order to leave comment. First, thank you for this one and the rest of tutorials on your website.
I have a file upload/sharing website and after i followed your tutorial i have had a few issues (having to update my apache because of certain rules in ssl-params, i was on Ubuntu 15.10, had to do an upgrade on my server over ssh, which failed at some point because of mysql 5.7 being not able to have blank port with phpmyadmin, well it was painful but at some point i managed to do the upgrade) but the biggest one was the “remote url upload”, Curl, which was not working anymore. I have checked all sort of things to disable verify_peer and verify_host but found that my file sharing script had already a false status on those. I was kinda lost and at some point i remember we had applied security parameters in ssl-params from a thirdparty that you were sharing here but that they could be the faulty ones. I tried to do an sudo a2disconf ssl-params, restartedapache and BINGO, it was working again. I then commented re-enable the ssl-params conf and isolated the faulty rule after commenting all of them one after the other. I’m here to share my finding, the faulty rule is
Header always set X-Frame-Options DENY
So in Shorter terms,
Comment this rule in /etc/apache2/conf-available/ssl-params.conf
#Header always set X-Frame-Options DENY
If you need CURL to work with this tutorial.
Thanks.
In my earlier comment I determined that it’s the “always” that’s the issue. Removing that word, but leaving the directive in place, will allow individual sites you configure to override that setting if you tell them to, but set it by default. Sort of a happy middle ground.
I had hard time to understand the difference between a Self-Signed SSL certificate and a CA one, despite your yellow information note (sorry I am a beginner :).
So here the stackoverflow answer on the matter that helped me to clearly understand the point:
The SSL certificate solves two purposes: encryption of traffic (for RSA key exchange, at least) and verification of trust. As you know, you can encrypt traffic with (or without, if we’re talking SSL 3.0 or TLS) any self-signed certificate. But trust is accomplished through a chain of certificates. I don’t know you, but I do trust verisign (or at least Microsoft does, because they’ve been paid lots of money to get it installed in their operating systems by default), and since Verisign trusts you, then I trust you too. As a result, there’s no scary warning when I go to such an SSL page in my Web browser because somebody that I trust has said you are who you are.
More: http://stackoverflow.com/questions/292732/self-signed-ssl-cert-or-ca
Great and easy understandable tutorial. Thank you for the invested time on writing it.
I´ve did all as you well describe on the tutorial, however now I´m facing an issue I´d like to know how to solve.
Despite it works and I´m able to access via HTTPS https://www.camarahispano-turca.org/
would like to know how to switch the “red warning” icon into the trustable “green shield” one
thanks for being patient since I´m newbie on all this server issues
First of all, thank you @justin for your great and easily understandable tutorial. It helps me a lot.
I´ve followed and did all you said on it and finally I achieved to connect the site via HTTPS [https://www.camarahispano-turca.org]
However, I´m not sure how I should do to get switch the “red warning” icon into the “green shield” one more trustable
Looking forward to hear from you
@info8da48d61aaf: Unfortunately, the red warning will remain for all self-signed certificates because web browsers are unable to validate it against a list of trusted certificate authorities that they maintain. This is usually fine for testing sites or for internal usage or if you do not have a domain.
If you need an SSL certificate for a public-facing site, the Let’s Encrypt project provides free certificates that will be recognized by all modern browsers. You can find out how to set up your server with a Let’s Encrypt certificate with Apache by following this guide. Since browsers are configured to trust certificates provided by Let’s Encrypt by default, the icon should turn to the “green shield” using this method. Hope that helps!
Thank you so much for the explication. I´d try the guide you recommend to get install the Let´s Encrypt certificate
So I have no Idea what I’m doing wrong, I’m getting a redirect loop when trying to go thru this guide with a domain name. Is that my problem? Should I just use the Let’sEncrypt service instead?
The weirdest part to is on part 4, it says that the syntax is OK. Could it be that I’m using CloudFlare as DNS?
Could you clarify how your 000-default.conf File looks? As that seems to be my problem… Have you done this with a domain name instead of ip?
@FilleFLEX1: I don’t currently have a server configured with this setup running right now, so I don’t have access to the
000-default.conffile right now. I did not use a domain name for this configuration however. I personally use Let’s Encrypt if I’m working with a server that has a domain name, as it’s a better solution in most cases where you’re not doing testing. If your domain is handled by CloudFlare, that could be related too. I don’t have much experience with that though, so I’m unable to confirmIf you feel like self-signed certs are best for your use-case and have tried to minimize interference from CloudFlare, the first thing I would check in that file would be whether your redirect line uses
httpsinstead ofhttp:You can also see if the logs have any details about the redirect. Those would likely be at
/var/log/apache2/access.logand/var/log/apache2/error.log.Good luck debugging and let me know how it goes. I’m sorry I wasn’t able to provide a direct solution.
The problems seems to be with the connection from my server and CloudFlare, when I booted up today it worked locally at least :) Just need to figure out what’s wrong with the CloudFlare end…
Also my question was, where in the config file did you put the line Redirect “/” “https://your_domain_or_IP/”, can you put it anywhere? And does those dots mean the rest of the text? Does it matter if you put it first or last in the document? And can you remove all the other bits?
Great guide anyways :)
P.S Should I post what I come up regarding the CloudFlare issue? It might be intresting for others, as they have a option to use a self-signed SSL key between your server and theirs, then they encrypt the communications between them and the client. Which results in you getting a greenlock and the communication is encrypted the whole way thru.
Edit: Well I feel like a fool now, as I forgot to allow the port 443 on my router :P Anyways it the CloudFlare thing works now, and I get greenlock with a self-signed SSL key which is kind of cool, might change to LetsEncrypt later. But this will do for now :)
@FilleFLEX1: Oh, sorry I misunderstood you last time. The
Redirectline can go anywhere within the virtualhost definition outside of all other blocks (don’t put it in aDirectoryblock for instance). The ordering shouldn’t matter.Once again, I’m not too familiar with CloudFlare, but one thing you could try to fix the redirect loop is to only redirect when the request is using HTTP. This part of the Apache docs has a similar example, showing how to direct an “admin” page to SSL. You could probably adapt that a bit.
I would try to see if something like this works:
Maybe that will short circuit the looping behavior you are seeing.
This post suggests checking the CloudFlare header as a condition of a rewrite. You may have better luck with that method.
Sorry again for being unclear :P
I got it to work, I got timed out, not redirected. And the reason was because I made the rookie mistake of forgetting to forward the port 443.
Thanks again for the super quick answers :)
Great Tutorial.
Everything works well, my only issue now being my SSH is broken in that WinSCP doesnt ask for a username or password and gives me 403 error method not allowed.
Anything specific i need to do in terms of downloading keys to use with WinSCP?
Not sure what the issue is here.
Any help would be greatly appreciated.
NVM i figured it out. changed the port to 22.
Silly mistake.
Great job on the Tut though!
I have successfuly installed the SSL ceritificate with the process given here.
But by default firewall was inactivate in apache server. The outcome of command “sudo ufw status” given as “Status: Inactive”. So I enabled the firewall with command “sudo ufw enable”. Now The outcome of command “sudo ufw status” given as
Output Status: active
To Action From
OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6)
But when I try to connect to my instance from putty. It is trowing the error message** “Network error: Connection timed out”.**
Please help me how to resolve this error
Note: Before I install the SSL certificate, I was able to connect to AWS EC2 install from putty. SSH, RDP, HTTPS connections are proper with required port numbers and IPs.
Thanks a lot for the tutorial!
I got this error in telegram webhook SSL error {336134278, error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed} what should i do?
I have tried to follow this tutorial as closely as possible starting from a one-click Ubuntu 16.04 LAMP deployment. However, when I go to my ip address in Firefox, I see “SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG”. Do you know what could be wrong?
Never mind. I missed the a2ensite default-ssl line the first time through.
How to do Apache – Authentication - SSL to a client using this self-signed certificate?
Great tutorial. Helps me a lot and save my life!!!
Great Tutorial. Worked perfectly and saved a reinstall of the OS. Also, after I completed your tutorial and had the default SSL site up, I was able to install Letsencrypt and it configured perfectly. Prior to this tutorial letsencrypt wouldn’t work, etc. Again, thank you for clear and concise writing.
Missing:
why is SSLStapling on if this is a self-signed certificate? When I leave this on I am getting
Hello! I followd this tutorial, and I didn’t changed anything (but the domain). I get this error in browser: ERR_SSL_PROTOCOL_ERROR What could this be? Thanks!
Hi, I have a question about a situation that I’m having… I have a trusted SSL certificate in my website and it’s works fine. But when I write in the browser the IP, e.g.: https://IP_ofMy_Web instead of my domain name, It takes me to the view with the SSL not trusted like in your example. If I write http://nameOfMyWeb redirects me to the https://nameOfMyWeb, so the redirect works fine, but, how can do I fix this situation with the IP? Thanks.
Hi, great tutorial.
I followed all the instructions till the end, no errors found!
However, when trying to access my https://localhost or https://127.0.1.1/ I’m getting the following error:
This site can’t provide a secure connection localhost sent an invalid response. ERR_SSL_PROTOCOL_ERROR
Any help would be very appreciated.
Thank you very much for the tremendous guide! Using this in part with the OwnCloud and LAMP setup, I’m looking forward to using this “weekend project” within my day-to-day tasks!
Thank you again!
Thanks for writing this!
Just a note that cause me to waste a bunch of time. I was trying to set all this up on a vhost as I didn’t know you couldn’t have more than one vhost per ip address and wasn’t aware of SNI. If you whoever is maintaining this put a note about that at the top it might help someone else save a bunch of time!
Still haven’t gotten it working correctly, but feel like I’m on the right track now.
Very good and useful guide thanks a lot! Worked first try
Great Article. Signed up just to write this comment. Awesome. Lots of thanks.
This is really a great tutorial! Thanks for sharing your knowledge with us! (Y)
Hello, so it is working bitcoinmerida.com
however, I want to add a new domain…
but I receive this error: SSLCertificateFile: file ‘/etc/letsencrypt/live/nimiqtalk.org/fullchain.pem’ does not exist or is empty
and indeed, I dont find, read, understand how this file gets created, I really need your help.
One last step, so your local computer will trust the certificate
https://unix.stackexchange.com/a/132163/188118
I followed this tutorial and Managed to set up the SSL on one of my Droplets However, I am getting this error on my Javascript web app Load denied by X-Frame-Options: https://*************************************.php?action=71&productid=1&fee=[{%22feeid%22:%221%22,%22feename%22:%22SIL%20PESA%20PF%22}]&valfutureinterest=1&valaccrueinterest=1&valallowloantopup=0&valpercentageoftopuploanpaid=0 does not permit framing.
SecurityError: Permission denied to access property “document” on cross-origin object
Cheers for the tutorial, although I came upon this error at the sudo apache2ctl configtest part
Any pointers?
Full disclosure, I am very new to all this
Thanks for this great Tutorial. Got more valuable information. May this link will help you to get more clarity about SSL certificate for apache.
thanks for this interesting tutorial
I’m trying to run an home web server for few web application and a cloud. I subscribed to no-ip dns service including a domain registration and several sub domain.
The aim is to call the web application with the subdomain. Let say this is the arrangement: Domain: mydomain.net Sub domains: aaa.mydomain.net, bbb.mydomain.net, ccc.mydomain.net Server name (the phisical machine) server.my domain.net (it is necessary or I can leave locahost or any other name)
With noip I have all A tape and I could also have *.mydomain.net (using wildcard) instead of single entry for each subdomain
When I need a ssl certificate do I need one for the mydomain.net and one for each sub.domain?
Similar question if I decide (more try) to get Let’s encrypt certificates
thanks a lot
Hi
When I run
in the Wordpress 1 Click App, I get the following error
I’m not sure how to update my server configuration to fix this. How do I go about it?
I have a self-signed certificate, but now i have a domain name, and i’d like to set a TLS/SSL certificate from Let’s Encrypt. If i follow this guide, it will overlap the self-signed? If not, how do i remove the self-signed certificate?
When I activate this conf, I only get erros and it obviosly doesn’t work. sudo a2enconf ssl-params
If I don’t it works perfect. So why is it in the doc?
After following these instructions and restarting apache my connection times out. Any idea what might be causing this?
This did not work for me, but if it did, it is not clear to me why I would want a visitor to a website to think that the connection is not secure. It is also not clear to me how this is supposed to work with LetsEncrypt. I will just undo all of the things that this tutorial setup by editing the files I changed and changing them back. To my thinking, a setup that combines redirection with LetsEncrypt so that users are redirected to a secure site would be useful, but that does not seem to be a part of the LetsEncrypt tutorial, because I have followed that tutorial and that is not what happens.
Hi everyone, would someone help/guide me in how to do this without having Diffie Hellman as my cipher please? I am trying to self-teach this and don’t want to guess and leave a step out, only to break the whole thing. I need to test using an IDS that does not support DH, otherwise it won’t decrypt. Thank you in advance :)