Tag Archives: ssl certificate

Private DNS Domains: Creating SSL Certs for Your Devices That Access Internal Servers (Updated November 23, 2023)

Leave a reply

So in my last post, we went over creating the SSL cert creation for your internal web servers. It was a nice, wildcard cert that was able to be made once and installed on many making it easier on us. Now we’ll go over making the CA certs for Android and Windows clients that will do away with that annoying Chrome nag screen about security and whatnot when accessing them and instead appear as a nice and secure website to the browser!

Crafting the Simple Configuration for Android

It’s necessary for a simple configuration for Android to have the certificate to be a CA cert. So this part establishes the part where we define that for a later step in the process.

[ req ]
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt             = no

[ req_distinguished_name ]
commonName = *.yourinternaldomain.local

[ req_ext ]
subjectAltName = @alt_names
basicConstraints=CA:TRUE

[alt_names]
DNS.1 = yourinternaldomain.local
DNS.2 = *.yourinternaldomain.local

Save it as openssl.cnf. So, this is basically exactly like the server cnf file except for one thing and that is the line where it says basicConstraints=CA:TRUE. That makes it so that you don’t get an error on importing it into Android and it will work correctly!

You do NOT need this cnf file for the Windows cert, just skip ahead!

Generating the Signing Key for Android/Windows

So, this is for both Android and Windows, it’s basically the same but with different extensions.

Android:

openssl genrsa -out privkey.pem 2048

Windows:

openssl genrsa -out privkey.key 2048

I use the different extensions here just to keep things straight in my head when working with creating these certificates because we create a .pem for Android and a .crt for Windows.

Creating the Certificate Signing Request for Android/Windows

Like in the server post is basically the same, just with a tweak to differentiate the Windows command signature some.

Android:

openssl req -new -key privkey.pem -out csr.pem -config openssl.cnf

Windows:

openssl req -new -key privkey.key -out cert.csr

So, on Android, you see that you reference the cnf file. Remember, if you are doing this on Windows, you must specify the complete DOS path to the cnf file in the command statement.

Generate the Certificate

So now we have that we can generate the two different types of certificates for Android and Windows.

Android:

openssl x509 -req -days 365 -in csr.pem -signkey privkey.pem -out cert.pem -extensions req_ext -extfile openssl.cnf

Windows:

openssl x509 -req -days 365 -in cert.csr -signkey privkey.key -out cert.crt
OR (Easier way, skip all the previous Windows steps and follow the Android steps and after generating the Android Cert just do this!)
openssl x509 -outform der -in cert.pem -out cert.crt

And there you go, certificates made, one last thing for those special devices that require attention.

Craft a Full Chain pem

Here’s how to create a quick Full Chain pem file.

cat cert.pem privkey.pem > fullchain.pem

Installing the Certs

On Windows, you want to install the cert into your Trusted Root Certificates store. I had to restart Chrome and refresh my servers (that were already running their brand new internal certs) to get the Good To Go widget in the address bar. I haven’t tested with Edge, but I assume being chromium-based it probably uses the Windows Certificate Store as well. No idea about Firefox, never had the urge to use it.

On Android 13, based on your specific device look up how to install a custom certificate on it and it should see cert.pem (which you should have emailed to yourself already) in your storage somewhere. I’ve read you’re supposed to be able to just tap the pem file and it will auto-install but that did not work on a Pixel or a Samsung device. I had to go into Settings and do it through the menu.

If you are on a Pixel that is running Android 14 like me then when you get the option from settings to select the cert, it will not show any pem files. I am not sure why, but I found a workaround. After you download it, open the Files app and delete it. Sounds crazy but stay with me. Then go into settings and go through the certificate settings to the point of picking the certificate. This should launch a Files-like window to select it, tap the 3 dots in the upper right and select Show Hidden Files. Then there you go, the deleted cert.pem file will be there and just tap it and it will be installed. Crazy I know but that worked on my Pixel 8 Pro.

That should be it for Android, just kill and relaunch Chrome and it should be like on your desktop and with no nag screen.

I generally hope this helps anyone who could use the help. I know it has reduced the years of numerous clicking and tapping to get passed the security alerts over the years.

John

Private DNS Domains: Creating SSL Certs for Your Web Servers and Devices That Access Them (Updated November 23, 2023)

Leave a reply

It’s pretty easy to get a growing internal network going at home now with devices getting cheaper and whatnot. But I myself don’t particularly don’t feel the need to expose them to the internet and only use them for myself. But I don’t like the nagging from Chrome about how this site is not secure for whatever reason on my Desktop or my tablet or phone. So I sat down this weekend and worked out how to create a cert for my web serving stuff and a CA cert for my end-use devices that made Chrome be quiet and happy and think everything was nice and secure. Here’s how I did it for the server side, later tomorrow or today I will add a post on how to do the client cert for you.

Install openssl on your working machine and buckle up!

Once you have openssl installed you need to do this twice, once for the Web servers and once for the CA for the end-user devices to accept that cert you made before.

The first thing is to generate a configuration file because we are going to make a wildcard certificate to keep from having to generate a cert for each server independently! Here’s the configuration example:

[ req ]
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt             = no

[ req_distinguished_name ]
countryName        = US
stateOrProvinceName = Texas
localityName       = Who Hee
organizationName   = Your Org
organizationalUnitName= Your Org Name
commonName = *.yourinternaldomain.local

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = yourinternaldomain.local
DNS.2 = *.yourinternaldomain.local

(Added more depth to CNF file)

Ok on *nix you can pretty much save that in whatever directory you are going to run the openssl command from as it will assume based on the prompt that it exists wherever it was executed from. Save the file as: openssl.cnf

On Windows, you need to change the below (like literally the text that follows below) areas where the openssl.cnf is mentioned to point to where the config is saved in the prompt.

Generate the Signing Key

Next up we generate the signing key:

openssl genrsa -out privkey.pem 2048

That is it!

Generate the Certificate Signing Request

Now we have to generate the CSR for generating our actual server cert.

openssl req -new -key privkey.pem -out csr.pem -config openssl.cnf (Updated to add -config option to CSR request)

That was nice and easy as well, now onto generating the server’s certificate!

Create the Actual Server Certificate

Now to the almost final step which is to create the cert to be installed on all the internal servers.

openssl x509 -req -days 365 -in csr.pem -signkey privkey.pem -out cert.pem -extensions req_ext -extfile openssl.cnf

Here is where we reference the openssl.cnf to get our wildcard cert. Remember Windows users to input the complete DOS path and use quotes if it has spaces to the actual cnf file.

Once Last Thing For Those Special Needs Servers

For those servers (i.e. Synology) that require a Full Chain pem file as well you can do this from *nix.

cat cert.pem privkey.pem > fullchain.pem

Ok, the server cert is done, you should be able to add it to your web servers now. I’ll be putting up the client portion for Android and Windows client CA certs sometime later today or tomorrow so that the annoying Chrome nag screen goes away.

John

Let’s Encrypt and Synology DSM: Creating SSL Wildcard Certificates

Leave a reply

In the realm of web security, SSL (Secure Sockets Layer) certificates play a pivotal role. They provide an encrypted link between a web server and a browser, ensuring all data passing between the two remains private and secure. Within the family of SSL certificates, a powerhouse stands out – the SSL Wildcard Certificate. As the name suggests, this certificate covers not only a single domain but all its subdomains too, making it a versatile and cost-effective solution for businesses with a wide web presence.

The SSL Wildcard Certificate is represented by an asterisk () before the domain name. This wildcard notation allows the certificate to secure unlimited subdomains under the primary domain. For instance, if a certificate is issued to “.domain.com,” it will secure “mail.domain.com,” “login.domain.com,” “blog.domain.com,” and so forth without needing separate certificates for each.

But what happens when you want to secure your Synology DiskStation Manager (DSM)? This is where the power of an SSL Wildcard Certificate shines. By integrating it with your Synology DSM, you can ensure comprehensive security across all your Synology services.

Why SSL Wildcard Certificates are Important for Securing Synology DSM

Synology DSM is a robust and versatile operating system for Synology NAS (Network Attached Storage) devices, allowing users to manage and protect their data efficiently. However, like all systems connected to the internet, it is vulnerable to cyber threats. This is why securing your Synology DSM with an SSL Wildcard Certificate is essential.

When you use an SSL Wildcard Certificate, you’re not just securing one service or domain; you’re securing all your subdomains under one umbrella. This means that whether you’re accessing your files via FileStation, managing emails through MailPlus, or sharing photos via Moments, your connection is secure. This universal coverage reduces the risk of cyberattacks, data breaches, and identity theft.

Moreover, an SSL Wildcard Certificate helps in building trust with your users. It validates your identity, proving to your users that they are indeed interacting with a secure, authentic Synology DSM. This boosts user confidence and can lead to increased user engagement.

Understanding the Basics of Let’s Encrypt and Synology Let’s Encrypt

To create an SSL Wildcard Certificate, we turn to Let’s Encrypt, a free, automated, and open Certificate Authority (CA). The magic of Let’s Encrypt lies in its simplicity and automation. It provides domain-validated certificates, including wildcard certificates, using an automated process designed to eliminate the current complex process of manual creation, validation, signing, and installation of certificates for secure websites.

Synology DSM supports Let’s Encrypt natively. This means that you can request, renew, and manage your SSL certificates from Let’s Encrypt directly within the DSM interface. However, for wildcard certificates, the process is slightly more complicated as it requires DNS validation. This is where the Windows Subsystem for Linux (WSL) and Ubuntu Image come into play.

Step-by-step Guide to Creating a Wildcard Certificate with Let’s Encrypt

Creating a wildcard certificate with Let’s Encrypt involves a few steps. First, you need to set up the Windows Subsystem for Linux (WSL) on your Windows machine. This requires a few steps, including enabling the WSL feature, downloading a Linux distribution (like Ubuntu) from the Microsoft Store, and setting up a new Linux instance.

Once you have WSL and Ubuntu set up, you can proceed to install Certbot, a tool designed to simplify the process of obtaining and managing Let’s Encrypt certificates. With a few commands in the Ubuntu terminal, you can install Certbot and its DNS plugin for your DNS provider, which will be used to automate the DNS validation process required for issuing a wildcard certificate.

After setting up Certbot, the final step is to generate your wildcard certificate. This involves running a command that tells Certbot to request a wildcard certificate for your domain, using the DNS plugin to handle the required validation. Upon successful validation, Let’s Encrypt will issue your wildcard certificate, which you can then find in the specified directory on your Linux instance.

Using WSL (Windows Subsystem for Linux) and Ubuntu Image for Certificate Creation

Using WSL and Ubuntu Image is a powerful way to create an SSL wildcard certificate. WSL allows you to run a Linux environment directly on Windows, without the need for a dual-boot setup or virtual machine. This means you can use Linux tools, like Certbot, on your Windows machine, making the process of creating a wildcard certificate much simpler and more efficient.

On the other hand, the Ubuntu Image provides a full-fledged Ubuntu environment, complete with a command-line interface. This means you can run Ubuntu commands directly on your Windows machine, providing further flexibility and efficiency when it comes to creating your wildcard certificate.

Together, WSL and Ubuntu Image provides a powerful, streamlined platform for creating SSL wildcard certificates. They provide all the tools and capabilities you need, all within a familiar Windows environment, reducing the complexity and time required to secure your Synology DSM.

Configuring Your Synology DSM for SSL Wildcard Certificate Installation

Once you’ve created your wildcard certificate using WSL and Ubuntu Image, the next step is to configure your Synology DSM for its installation. This involves uploading the certificate to your DSM and assigning it to your services.

First, you need to log into your DSM and navigate to the Control Panel, then to Security, and finally to the Certificate tab. Here, you can upload your new wildcard certificate, which consists of the certificate itself, its private key, and the chain of trust.

After uploading the certificate, you need to assign it to your services. This means telling your DSM which services should use the new wildcard certificate. By assigning the wildcard certificate to all your services, you ensure that they are all secured with the same, consistent level of encryption.

Testing and Verifying the SSL Wildcard Certificate

After installing the SSL wildcard certificate on your Synology DSM, it’s important to test and verify that it’s working correctly. This involves checking that all your services are accessible via HTTPS and that no security warnings are shown when accessing them.

To test your certificate, simply try accessing your services using their HTTPS URLs. For example, if you have a service at “mail.domain.com,” try accessing “https://mail.domain.com.” If the page loads without any security warnings, then your wildcard certificate is working correctly.

Additionally, you can use online SSL checkers to verify your certificate. These tools will check the validity of your certificate and its chain of trust, ensuring that it’s correctly installed and trusted by browsers.

Troubleshooting Common Issues During the Certificate Installation Process

Despite the simplicity and automation provided by Let’s Encrypt, WSL, and Ubuntu Image, you may still encounter issues during the certificate installation process. The most common issues include validation failures, certificate upload problems, and certificate assignment errors.

Validation failures occur when Let’s Encrypt is unable to verify your domain ownership. This usually happens due to incorrect DNS settings. To resolve this issue, double-check your DNS settings and make sure that they match what’s required by Let’s Encrypt for DNS validation.

Certificate upload problems, on the other hand, occur when you’re unable to upload your certificate to your Synology DSM. This can happen due to incorrect file formats or permissions. To resolve this issue, ensure that your certificate files are in the correct format (PEM) and that they have the correct permissions (readable by the DSM).

Finally, certificate assignment errors occur when you’re unable to assign your certificate to your services. This usually happens due to incorrect service settings. To resolve this issue, double-check your service settings and make sure that they allow for custom SSL certificates.

Benefits and Advantages of Using SSL Wildcard Certificates for Synology DSM

The benefits and advantages of using SSL Wildcard Certificates for Synology DSM are numerous. First and foremost, they provide a high level of security. By securing all your subdomains with a single certificate, you ensure that all your services are protected with the same level of encryption, reducing the risk of cyberattacks and data breaches.

Second, SSL Wildcard Certificates are cost-effective. Instead of purchasing individual certificates for each of your subdomains, you can secure all of them with a single certificate, saving money and reducing administrative overhead.

Finally, SSL Wildcard Certificates are versatile. They can be used with any service on your Synology DSM, providing a flexible and scalable solution for securing your data and services.

Final Thoughts

In conclusion, securing your Synology DSM with an SSL Wildcard Certificate is a powerful and efficient way to protect your data and services. By leveraging the power of Let’s Encrypt, WSL, and Ubuntu Image, you can create and install your wildcard certificate, ensuring a high level of security across all your subdomains.

While the process may seem complex at first, the benefits and advantages of using SSL Wildcard Certificates for Synology DSM far outweigh the initial learning curve. They provide a high level of security, are cost-effective, and offer unmatched versatility, making them an ideal solution for any Synology DSM user.

So, don’t wait. Harness the power of SSL Wildcard Certificates today and protect your Synology DSM with the security it deserves.

John