Search the Community

Disk Station Manager v7 (DSM 7) is the operating system of Synology NAS devices. You can configure the Let’s Encrypt SSL certificates for your Synology NAS from the DSM 7 web interface. By default, Synology DSM 7 uses the HTTP-01 challenge to verify the ownership of the domain (that you want to use for your Synology NAS) and issue an SSL certificate for the domain. But the HTTP-01 challenge won’t work unless you have a public IP address and your computer is accessible from the internet. So, if you want to use the Let’s Encrypt SSL certificates for your home network or private network, you have to use the DNS-01 challenge instead. When the DNS-01 challenge is used, Let’s Encrypt verifies the ownership of the domain using the DNS server of the domain. So, it works for private networks as well. Sadly, the Synology DSM 7 web interface does not provide any way of obtaining the Let’s Encrypt SSL certificates using the DNS-01 challenge. Luckily, the “acme.sh” program can be installed on your Synology NAS and is used to generate and renew the Let’s Encrypt SSL certificates using the DNS-01 challenge. In this article, we will show you the following: How to install “sh” on your Synology NAS How to use “acme.sh” to generate a Let’s Encrypt SSL certificate (via the DNS-01 challenge) for the domain name that you’re using on your Synology NAS How to install the “acme.sh” generated Let’s Encrypt SSL certificate on your Synology NAS How to configure the DSM 7 operating system of your Synology NAS to use the generated Let’s Encrypt SSL certificate How to configure your Synology NAS to automatically renew the generated Let’s Encrypt SSL certificates using “acme.sh” NOTE: In this article, we will use the CloudFlare DNS server for demonstration. You can use other DNS services that are supported by acme.sh as well. All you have to do is make the necessary adjustments. Topic of Contents: Creating a Certadmin User on Synology NAS Configuring the CloudFlare DNS Server for LetsEncrypt DNS-01 Challenge Configuring Other DNS Services for LetsEncrypt DNS-01 Challenge Accessing the Synology NAS Terminal via SSH Downloading Acme.sh on Your Synology NAS Installing Acme.sh on Your Synology NAS Generating a Let’s Encrypt SSL Certificate Using Acme.sh for Your Synology NAS Installing the Let’s Encrypt SSL Certificate on Your Synology NAS Using Acme.sh Setting the Let’s Encrypt SSL Certificate as Default on Your Synology NAS Configure Synology NAS to Auto Renew a Let’s Encrypt SSL Certificate Using Acme.sh Conclusion References Creating a Certadmin User on Synology NAS First, you should create a new admin user on your Synology NAS to generate and renew the Let’s Encrypt SSL certificates. To create a new admin user on Synology NAS, click on Control Panel[1] > User & Group[2] from the DSM 7 web interface. Click on “Create” from the “User” tab. Type in “certadmin” as the user name[1], an optional short description for the user[2], the user login password[3], and click on “Next”[4]. To create an admin user, tick the “administrators” group from the list[1] and click on “Next”[2]. Click on “Next”. Click on “Next”. Click on “Next”. Click on “Next”. Click on “Done”. The certadmin user should now be created on your Synology NAS. Configuring the CloudFlare DNS Server for Let’s Encrypt DNS-01 Challenge To use the CloudFlare DNS server for the Let’s Encrypt DNS-01 challenge, you need to generate a CloudFlare DNS token. You can generate a CloudFlare DNS server token from the CloudFlare dashboard. For more information, read this article. Configuring Other DNS Services for Let’s Encrypt DNS-01 Challenge “Acme.sh” supports other DNS services. If you don’t want to use the CloudFlare DNS, you can use any one of the “acme.sh” supported DNS services. The configuration is a little bit different for different DNS services. For more information, check the “acme.sh” DNS API guide. Accessing the Synology NAS Terminal via SSH To install “acme.sh” and generate and install a Let’s Encrypt SSL certificate on your Synology NAS, you need to access the Terminal of your Synology NAS. For more information on enabling the SSH access on your Synology NAS and accessing the Terminal of your Synology NAS, read this article. Once you enabled the SSH access on your Synology NAS, open a terminal app on your computer and run the following command: $ ssh certadmin@<ip-domain-of-your-synology-nas> You will be asked to type in the login password of the certadmin user. Type in the login password of the certadmin user of your Synology NAS and press on <Enter>. You should be logged in to your Synology NAS as the certadmin user. Downloading Acme.sh on Your Synology NAS To download the latest version of the “acme.sh” client, run the following command: $ wget -O /tmp/acme.sh.zip https://github.com/acmesh-official/acme.sh/archive/master.zip The latest version of the “acme.sh” client archive “acme.sh.zip” should be downloaded in the “/tmp” directory of your Synology NAS. Installing Acme.sh on Your Synology NAS To extract the “/tmp/acme.sh.zip” archive in the “/usr/local/share” directory of your Synology NAS, run the following command and type in the login password of the certadmin user and press <Enter> when prompted for the password. The “/tmp/acme.sh.zip” archive should be extracted in the “/usr/local/share/acme.sh-master” directory. $ sudo 7z x -o /usr/local/share /tmp/acme.sh.zip For simplicity, rename the “acme.sh-master” directory to just “acme.sh” with the following command: $ sudo mv -v /usr/local/share/acme.sh-master /usr/local/share/acme.sh To make the certadmin user owner of the “/usr/local/share/acme.sh” directory and its contents, run the following command: $ sudo chown -Rfv certadmin /usr/local/share/acme.sh Generating a Let’s Encrypt SSL Certificate Using Acme.sh for Your Synology NAS To generate a Let’s Encrypt SSL certificate for the domain name that you’re using on your Synology NAS, navigate to the “/usr/local/share/acme.sh” directory as follows: $ cd /usr/local/share/acme.sh Now, you need to export the required DNS API token environment variables. We use the CloudFlare DNS to manage the domain name that we are using on our Synology NAS. So, for us, all we have to do is export the CF_Token environment variable with the value of the CloudFlare DNS API token. If you’re using some other DNS service, check the “acme.sh” DNS API documentation for the variables that you need to export for “acme.sh” to work with your DNS service. $ export CF_Token="<CloudFlare DNS API Token>" Also, export the required Synology environment variables so that “acme.sh” can install the generated SSL certificates on your Synology NAS. $ export SYNO_Username="certadmin" $ export SYNO_Password="Your_certadmin_login_Password" $ export SYNO_Certificate="Let’s Encrypt" $ export SYNO_Create=1 To generate a Let’s Encrypt SSL certificate for the “*.nodekite.com” (wildcard) domain name using the CloudFlare DNS plugin (–dns dns_cf), run the following command: $ ./acme.sh --server letsencrypt --issue --dns dns_cf --home $PWD -d "*.nodekite.com" NOTE: If you’re using other DNS services, you need to change the DNS plugin (–dns <dns-plugin-name>) in the previous command accordingly. For more information, check the “acme.sh” DNS API documentation. A Let’s Encrypt SSL certificate is being generated. It takes a while to complete. At this point, the Let’s Encrypt SSL certificate should be generated. Installing the Let’s Encrypt SSL Certificate on Your Synology NAS Using Acme.sh Once the Let’s Encrypt SSL certificate is generated for the domain name (*.nodekite.com in this case) of your Synology NAS, you can install it on your Synology NAS with the following command: $ ./acme.sh -d "*.nodekite.com" --deploy --deploy-hook synology_dsm --home $PWD If you have a two-factor authentication enabled for the certadmin user, you will receive an OTP code. You have to type in the OTP code and press <Enter>. If you don’t have the two-factor authentication enabled for the certadmin user, leave it empty and press <Enter>. Press <Enter>. The generated Let’s Encrypt SSL certificate should be installed on your Synology NAS. Once the Let’s Encrypt SSL certificate is installed on your Synology NAS, it will be displayed on the Control Panel > Security > Certificate section of the DSM 7 web interface of your Synology NAS. Setting the Let’s Encrypt SSL Certificate as Default on Your Synology NAS To manage the SSL certificates of your Synology NAS, navigate to the Control Panel > Security > Certificate section from the DSM 7 web interface of your Synology NAS. To set the newly installed Let’s Encrypt SSL certificate as the default so that the newly installed web services on your Synology NAS will use it by default, select the Let’s Encrypt SSL certificate and click on Action > Edit. Tick on “Set as default certificate”[1] and click on “OK”[2]. The Let’s Encrypt SSL certificate should be set as the default certificate for your Synology NAS. To configure the existing web services of your Synology NAS to use the Let’s Encrypt SSL certificate, click on “Settings”. As you can see, all the web services are using the Synology self-signed SSL certificate. To change the SSL certificate for a web service, click on the respective drop-down menu from the right. Then, select the Let’s Encrypt SSL certificate that you want to use for the web service from the drop-down menu. In the same way, select the Let’s Encrypt SSL certificate for all the installed web services of your Synology NAS and click on “OK”. Click on “Yes”. The changes are being applied. It takes a few seconds to complete. Once the Let’s Encrypt SSL certificate is applied to all the web services of your Synology NAS, refresh the web page and your DSM 7 web interface should use the Let’s Encrypt SSL certificate. Configuring Synology NAS to Auto Renew the Let’s Encrypt SSL Certificate Using Acme.sh To configure your Synology NAS to automatically renew the Let’s Encrypt SSL certificate, navigate to Control Panel > Task Scheduler from the DSM 7 web interface. From the Task Scheduler, click on Create > Scheduled Task > User-defined script. From the “General” tab, type in “Renew SSL Certs” in the “Task” section[1] and select “certadmin” from the “User” dropdown menu[2]. From the “Schedule” tab, select “Run on the following date”[1] and select “Repeat monthly” from the “Repeat” dropdown menu[2]. Navigate to the “Task Settings” tab, type in the following command in the “User-defined script” section [1], and click on “OK”[2]. /usr/local/share/acme.sh/acme.sh –renew –server letsencrypt -d “*.nodekite.com” –home /usr/local/share/acme.sh A new task should be created. The “Renew SSL Certs” task will run every month and make sure that the Let’s Encrypt SSL certificate is renewed before it expires. Conclusion In this article, we showed you how to install and use the “acme.sh” ACME client to generate a Let’s Encrypt SSL certificate via the DNS-01 challenge on your Synology NAS. We also showed you how to install the generated Let’s Encrypt SSL certificate on your Synology NAS and configure the web services of your Synology NAS to use it. Finally, we showed you how to configure a scheduled task on your Synology NAS to automatically renew the Let’s Encrypt SSL certificate before it expires. References: Synology DSM 7 with Lets Encrypt and DNS Challenge Automatically renew Let’s Encrypt certificates on Synology NAS using DNS-01 challenge acmesh-official/acme.sh: A pure Unix shell script implementing ACME client protocol View the full article

Have you ever encountered this frustrating error message when trying to make an HTTPS request from your .NET application? “System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.” If so, you are not alone. This error is quite common; it means that your client application cannot establish a secure connection with the server. In this article, I will show you how to diagnose and fix this error. What Does the Error Mean?The "Could not create SSL/TLS secure channel" error occurs when your application fails to establish a secure connection with the web server using the SSL/TLS protocol. SSL/TLS stands for Secure Sockets Layer/Transport Layer Security, a standard protocol for encrypting and authenticating data over the internet. When your application makes a web request, it initiates a "handshake" process with the webserver to negotiate the encryption and authentication parameters. This process involves exchanging certificates, keys, and cipher suites to ensure that both parties can communicate securely. If this process fails for any reason, the error is thrown. Check our article on Certified Kubernetes Administrator Exam Series (Part-6): Security, to get a better understanding of Kubernetes security. Why Does the Error Happen?There are many possible reasons why the error can happen, but they can be broadly categorized into client-side and server-side issues. Client-side issues: These are problems related to the configuration and settings of your application, such as the SSL/TLS protocol version, the security policy, the certificate validation, and the proxy settings. These issues can be fixed by changing the code or the configuration of your application. Server-side issues: These are problems related to the configuration and settings of the web server, such as the SSL/TLS protocol version, the certificate chain, the cipher suites, and the firewall rules. These issues can be fixed by changing the configuration or the code of the web server or by contacting the web service provider. Some of the common causes of the error are: The web server does not support the SSL/TLS protocol version that your application is using. The web server does not have a valid certificate, or the certificate is not trusted by your application. The web server does not support the cipher suites that your application is using.How to Fix the Error?Below are the different ways of troubleshooting and fixing the error. Scenario 1: The server does not support the SSL/TLS protocol version that your application is usingThis scenario can happen when the server is configured to use a higher or a lower protocol version than your application. For instance, the server may only support TLS 1.2 or higher while your application uses TLS 1.0 or lower. To diagnose this scenario, you can use Fiddler to see the protocol version your application and the server are using. To fix this scenario, you can either change the protocol version of your application or the web server so that they match or are compatible. To change the protocol version of your application, you can use the ServicePointManager.SecurityProtocol property. For example, to use TLS 1.2, you can add the following line of code before making the HTTPS request: ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls1.2; To change the protocol version of the server, you need to contact the server administrator or refer to the server documentation. Scenario 2: The server certificate is not trusted by your application or the systemThis scenario can happen when the server certificate is self-signed, expired, revoked, or issued by an untrusted authority. For example, the server may use a certificate that is generated by itself or by a private certificate authority that is not recognized by your application or the system. To troubleshoot this scenario, you can use Fiddler or Wireshark to see the server certificate and its trust chain. In Fiddler, you can see the server certificate by clicking on the padlock icon in the Sessions list and then clicking on the Certificates tab. In Wireshark, you can see the server certificate by expanding the ssl.handshake.certificate field of the ServerHello packet. To fix this scenario, you can either trust the server certificate or bypass the certificate validation. To trust the server certificate, add it to the list of trusted root certificates of your application or the system. In Windows, you can use the Certificate Manager tool (certmgr.msc) to import the certificate to the Trusted Root Certification Authorities store. Alternatively, you can use the X509Store class in .NET to programmatically add the certificate to the store. Below is a code sample that adds the certificate from a file. Using System.Security.Cryptography.X509Certificates; // Load the certificate from a file X509Certificate2 cert = new X509Certificate2("server.crt"); // Open the trusted root store X509Store store = new X509Store(StoreName.Root, StoreLocation.LocalMachine); store.Open(OpenFlags.ReadWrite); // Add the certificate to the store store.Add(cert); // Close the store store.Close(); To bypass the certificate validation, you can use the ServicePointManager.ServerCertificateValidationCallback property to specify a custom delegate that always returns true. Below is a code sample that ignores any SSL policy errors using System.Net; using System.Net.Security; using System.Security.Cryptography.X509Certificates; // Define a custom delegate that always returns true bool ValidateServerCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { return true; } // Assign the delegate to the callback property ServicePointManager.ServerCertificateValidationCallback = ValidateServerCertificate;However, bypassing the certificate validation is not recommended, as it can expose your application to security risks like a man-in-the-middle attack. You should only use this option for testing purposes or when you trust the server completely. Check our course on Docker Certified Associate Exam Series (Part-6): Docker Engine Security, to learn how to secure your Docker hosts using TLS certificates. Scenario 3: The cipher suites supported by the server and your application do not matchThis scenario can happen when the server and your application have different preferences or requirements for the cipher suites that they use in the SSL/TLS session. For example, the server may only support strong cipher suites that use AES encryption and SHA-256 hashing, while your application may only support weak cipher suites that use RC4 encryption and MD5 hashing. Or the server may require a cipher suite that uses elliptic curve cryptography (ECC), while your application does not support ECC. Use Fiddler or Wireshark to see the cipher suites that your application and the server are offering and selecting. For example, in Fiddler, you can see the cipher suites in the Ciphers column of the Sessions list. In Wireshark, you can see the cipher suites in the ssl.handshake.ciphersuites field of the ClientHello and ServerHello packets. To fix this scenario, you can either change the cipher suites of your application or the server so that they have at least one common cipher suite. To change the cipher suites of your application, use the ServicePointManager.CipherSuites property. For example, to use only the cipher suites that use AES encryption and SHA-256 hashing, integrate the following code: using System.Net; using System.Net.Security; // Define a list of cipher suites that use AES and SHA-256 TlsCipherSuite[] cipherSuites = new TlsCipherSuite[] { TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TlsCipherSuite.TLS_RSA_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_RSA_WITH_AES_128_GCM_SHA256 }; // Assign the list to the property ServicePointManager.CipherSuites = cipherSuites;To change the server's cipher suites, you may need to contact the server administrator. How to test your HTTPS connection and verify that it is secure? After you have fixed the error and established a successful SSL/TLS connection with the server, you may want to test your connection and verify that it is secure. Below are some of the ways to do that: Use Fiddler or Wireshark to inspect the encrypted data that is exchanged between your application and the server. You can see the data in the Text View or Hex View tabs of Fiddler, or in the ssl.app_data field of Wireshark. You can also see the encryption algorithm and the key length that are used in the session in the Ciphers column of Fiddler, or in the ssl.cipher field of Wireshark.Use online tools such as SSL Labs or Qualys SSL Server Test to scan the server and check its SSL/TLS configuration and security. These tools can give you a detailed report on the server certificate, the protocol version, the cipher suites, and the vulnerabilities that the server may have. They can also give you a rating on the server’s SSL/TLS security, from A+ to F.Use the SslStream class to get information about the SSL/TLS session, such as the protocol version, the cipher suite, the key exchange algorithm, and the hash algorithm. You can access these properties from the SslStream object that is returned by the WebRequest.GetRequestStream or the HttpClientHandler.SslProtocols methods. Below is a sample code that gets the protocol version and the cipher suit.using System.Net; using System.Net.Security; // Create a web request to the server WebRequest request = WebRequest.Create("https://example.com"); // Get the request stream SslStream stream = (SslStream)request.GetRequestStream(); // Get the protocol version and the cipher suite string protocol = stream.SslProtocol.ToString(); string cipher = stream.CipherAlgorithm.ToString(); // Print the information Console.WriteLine("Protocol: {0}", protocol); Console.WriteLine("Cipher: {0}", cipher); Interested in learning more about Kubernetes security? Check out the following articles and courses from KodeKloud: 10 Kubernetes Security Best Practices to Secure K8 ClustersDevSecOps – Kubernetes DevOps & SecurityCertified Kubernetes Security (CKS): ConclusionIn this article, we have seen how to diagnose and fix the “Could not create SSL/TLS secure channel” error. I have also shown you how to test your HTTPS connection and verify that it is secure. I hope you have found this article helpful and interesting. If you have any questions or feedback, please feel free to leave a comment below. If you're keen on learning more about DevOps, simply sign up for a free account on KodeKloud. As a member, you'll gain access to over 70 courses, labs, quizzes, and projects designed to enhance your proficiency in various DevOps skills. View the full article

Our world has gone digital and information is more frequently exchanged online. The data shared makes it imperative for us to have secure connections. SSL.....View the full article

Learn how to launch an Apache Kafka with the Apache Kafka Raft (KRaft) consensus protocol and SSL encryption. This article is a continuation of my previous article Running Kafka in Kubernetes with KRaft mode... View the full article

Don’t be surprised if you have seen the Certificate Update in the Amazon Relational Database Service (Amazon RDS) console. If you use or plan to use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) with certificate verification to connect to your database instances of Amazon RDS for MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, and Amazon Aurora, it means you should rotate new certificate authority (CA) certificates in both your DB instances and application before the root certificate expires. Most SSL/TLS certificates (rds-ca-2019) for your DB instances will expire in 2024 after the certificate update in 2020. In December 2022, we released new CA certificates that are valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1). So, if you rotate your CA certificates, you don’t need to do It again for a long time... View the full article

AWS Certificate Manager (ACM) now publishes certificate metrics and events through Amazon CloudWatch and Amazon EventBridge. Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates are used to secure network communication and establish the identity of websites over the internet. Certificates have a defined lifetime and for continued use need to be renewed before they expire. These new metrics and events help administrators keep track of certificate expiration dates and take necessary action or configure automation to prevent certificate expiry and related outages. View the full article

Amazon Neptune now enforces a minimum version of TLS v1.2 and Secure Sockets Layer (SSL) client connections to Neptune in all AWS Regions where Neptune is available with the latest engine release, 1.0.4.0. View the full article

ACM for Nitro Enclaves is an enclave application that allows you to use public and private SSL/TLS certificates with your web applications and servers running on Amazon EC2 instances with AWS Nitro Enclaves. SSL/TLS certificates are used to secure network communications and establish the identity of websites over the Internet as well as resources on private networks. Nitro Enclaves is an EC2 capability that enables creation of isolated compute environments to protect and securely process highly sensitive data, such as SSL/TLS private keys. View the full article