It how to create a self signed security (ssl) certificate and deploy it to client machines

Set up local test domains and enable a trusted, self-signed certificate for quick, local testing

Most of the time, we’ll have domains other than the localhost to test the applications locally, and we’ll also need trusted self-signed SSL certificates.

A self-signed certificate is a certificate that’s signed by the person creating it rather than a trusted certificate authority. The development servers can be enabled with self-signed certificates that’ll help us reduce the certificate cost and also the management overheads.

By default, the self-signed certificate throws a certificate-validation error when accessing the websites in browsers but will allow us to proceed to the actual pages by accepting the risk. In some cases, the self-signed certificates won’t help us test some of the browser functionalities that only work through valid SSL — e.g., testing different browsers’ APIs, like geolocation.

Let’s now see how to quickly set up the local domains and a trusted self-signed certificate for testing in Windows. the same can be used in other systems with some additional steps.

Sometimes we may need to have different domains to test our application in the development environment. The DNS setup will consume more time and cost; the local domains help us to test the applications quickly in development environments.

I’m going to define the following test domains — myexample.com , sub.myexample.com , and myexample1.com .

Edit the Windows hosts file, C:\Windows\System32\drivers\etc\hosts . Add the below entries to map the test domains to 127.0.0.1 so the defined domains will be able to access the application running on the localhost within the same machine.

Let’s now create a self-signed certificate through OpenSSL.

Create an RSA-2048 key, and save it to the file rootCA.key .

When you get “Enter passphrase for rootCA.key,” enter a passphrase and store it securely.

Create a root certificate through the key generated.

Change the validity days as needed.

When you get “Enter passphrase for rootCA.key,” enter the passphrase used while generating the root key.

Enter the other optional information:

• Country Name (2 letter code) [AU]: US
• State or Province Name (full name) [Some-State]: MN
• Locality Name (e.g., city) []: Eagan
• Organization Name (e.g., company) [Internet Widgits Pty Ltd]: Tech Forum
• Organizational Unit Name (e.g., section) []: Marketing
• Common Name (e.g., server FQDN or YOUR name) []: Local certificate
• Email Address []: [email protected]

Now the root certificate is ready. Let’s trust the root SSL certificate in the local system.

Run the below command through the command prompt (run through elevated access):

Now the root certificate is added as part of the Trusted Root Certification Authorities.

You can verify the certificate through Certificate Manager or Certmgr.msc .

Even the root certificate can be managed through browsers: In Chrome, navigate to Settings → Privacy and Security → Security → Manage Certificates → Trusted Root Certification Authorities.

You can import/export and remove the certificate (the certificates can’t be removed if it was imported through Certmgr.msc ):

If you use Firefox for local testing, it won’t consider the root certificates from the Windows cert store(Chrome and Edge refer to the root certificates from the Windows cert store). The self-signed root certificate should be imported to Firefox separately.

Navigate to Options→ Privacy and Security → Security → Certificates → View Certificates.

You can import/export and remove the certificates. Import the Root CA certificate generated in the earlier steps. Select “Trust this CA to identify websites.”

The root certificate is trusted now. Let’s issue an SSL certificate to support our local domains — myexample.com , sub.myexample.com , myexample1.com , and localhost for testing.

Create a new OpenSSL configuration file server.csr.cnf so the configurations details can be used while generating the certificate.

Create a v3.ext file with a list of local SAN domains:

Create a private key and certificate-signing request (CSR) for the localhost certificate.

This private key is stored on server.key .

Let’s issue a certificate via the root SSL certificate and the CSR created earlier.

When it says “Enter passphrase for rootCA.key,” enter the passphrase used while generating the root key.

The output certificate is stored in a file called server.crt .

This article describes the steps on how to deploy a self-signed certificate by using group policy in Windows Server 2019 Active Directory. This procedure is useful when you need to push a WSUS self-signed or CA-signed certificate to all of your clients before they can trust the published third party packages.

In the previous post, we have seen the steps on how to bind the self-signed certificate in IIS 10. If you are using a self-signed certificate, then domain users are going to get an error in browsers (IE/Firefox) that the certificate is not valid.

To fix this in our domain, we will create a Group Policy and deployed the self-signed certificate to each client. Group policy will add the self-signed certificate to the trusted root certification authorities list on each client. So clients can trust the self-signed certificate.

1: Export the Self-signed Certificate:

First of all, we need to export the self-signed certificate from your web server.

1. To do so, open the run menu by pressing Windows Key and R key at the same time. Type mmc and press enter key.

3. Expand Certificates (Local Computer). Expand Personal and click on Certificate from the menu on the left-hand side.

4. Right-click on your Self-signed certificate and choose All Tasks followed by Export.

5. Click Next on Welcome wizard.

6. Choose No, do not export the private key. Click Next.

Now we are ready to create the certificate deployment policy. We should open the Group Policy Management console to create a group policy object.

2. Create and apply Group Policy Object (GPO):

10. On server manager console, click on tools and select group policy management.

14. Navigate to Computer Configuration – Policies – Windows Settings – Security Settings – Public Key Policies – Trusted Root Certification Authorities.

15. Right-click in the right pane and select Import.

3: Test group policy settings on client machine:

21. All you need to do now is run a gpupdate /force command on a computer to test the group policy.

You have now successfully deployed the self-signed certificate to all client machines using group policy. The self-signed certificate will be automatically installed on all new computers without requiring any involvement.

Hi. How are you? Let’s continue exploring the features of Windows Server 2019. In this opportunity, we will talk about how to create self signed certificates on Windows Server 2019. In the first place let’s define what is an SSL (Secure Socket Layer) Certificate. It encrypts all data between the server and the client’s browser. Consequently, if an attacker wants to access the information exchanged between the two, he won’t be able to decipher it. As you can see, it is a fundamental aspect of the security of a website. In addition, it is indispensable to be able to activate HTTPS on the site.

Generating SSLcertificates

On the other hand, there are several sites online to acquire these certificates: comodo, Symantec and GlobalSign for example. These sites offer SSL certificates at different prices, depending on the customer’s needs. However, we have the possibility to generate self-signed certificates using Windows Server 2019. For this, we will use Internet Information Services, if you don’t know how to activate it, go through our tutorial. Obviously, the effectiveness of a self-signed certificate is less than that of one signed by a company. However, we can use these certificates to work on our intranet or publish sites on the Internet as well. So let’s see how to create self signed certificates on Windows Server 2019.

Create self signed certificates using IIS manager

From the Server Manager, locate IIS in the left pane.

IIS

Then right-click on the server and run the IIS manager

Running Internet Information Services (IIS) Manager

Click on the name of the server in the left column connections. Then double click on Server Certificates

Select Server Certificates

In the right column, select Create Self-Signed Certificate.

Create Self-Signed Certificates

Choose the name of your preference to identify the certificate and press OK to continue.

Specify a friendly name to the new certificate

Finally, we have a certificate valid for one year. We can see it in the section Server Certificates

Certificate finally generated

Testing the certificate.

To test the performance of the certificate we just created, we will open the IIS Manager.

Binding the certificate

Next, press the Add button.

Adding the self signed certificate

In the next window, click on Type and select https, then on SSL Certificate choose the newly created certificate and press OK to continue.

Select the new SSL certificate

We should now see the bindings for port 443. Next, press the Add button. Now close the window to finish.

Site Bindings

All right, let’s try the new certificate. In the IIS Manager, go to the Action panel on the right and select Browse *.443 (https).

Browse https site

We’ll immediately see a security alert. This is because the browser cannot verify the authenticity of the certificate since the website is the one that provides the information. We must establish an exception to this alert by clicking on advanced, and then on Accept the risk and continue.

Adding an exception to localhost

Once this is done, we’ll see the https navigation enabled on the website.

Localhost with https activated

Conclusion

We have seen how to generate a self-signed certificate in Windows Server 2019. As we already mentioned, this will be of great help to the security of our websites. I hope you enjoyed this tutorial, in next releases, we will continue studying on Windows Server 2019. In fact, let’s see how to generate error-free SSL certificates for local development. In conclusion, has been a profitable way up to here, before saying goodbye I want to invite you to join our group on Facebook.

In this post, we will set up a two-way SSL from CA-signed certificate hosted as a server and a client-server and demonstrate the connectivity between client and server.

Join the DZone community and get the full member experience.

What is Two-Way SSL?

Two-way SSL means that a client and a server communicates on a verified connection with each other. The verifying is done by certificates to identify. A server and a client has implemented a private key certificate and a public key certificate.

Two-way SSL representative:

Let’s get into a demonstration on how the client and server setup is done and could be used in real-world case scenario.

We will proceed with the below steps:

• Create a server setup.
• Integrate it with Mule and deploy it locally.
• Create a client setup.
• Import client public certificate(.crt) to server truststore.
• Import server public certificate(.crt) to client truststore.

Create a Server Setup

1. Generate a CSR along with private Key.
   openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr (It will prompt some questions like country name, organization etc.)
   Note: Please make sure you provide a proper common name(Common Name (your name or your server’s hostname))
   You can view and verify the information contained in the CSR
   openssl req -noout -text -in server.csr
2. Either you can Self-Sign the certificate or provide your CSR to Authorised (Skip this step if you are not self-signing it)
   openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt For CA-signed, an Approved Authority will provide you the .crt file
   Note: Two-way SSL will only happen on CA-signed certificate
3. Create a JKS file using .crt file and private key
   You must generate a p12 file which comprises of private and .crt file
   openssl pkcs12 -export -in server.crt -inkey server.key -certfile server.crt -out server.p12
   Now you must generate jks using a p12 file.
   keytool -importkeystore -srckeystore server.p12 -srcstoretype pkcs12 -destkeystore server.jks -deststoretype JKS
   Change the alias server.jks. Above command set the alias for server.jks to 1. To rename it use this command:
   keytool -changealias -keystore server.jks -alias 1
4. Add the JKS to your Keystore and deploy your API using HTTPs
   You can view your certificate through the browser. It would be unsecure for self-signed and secure for CA-signed
   You can view your certificate through a browser. It would be unsecure for self-signed and secure for CA signed. Now you will have the below files generated:
   1. server.crt
   2. server.csr
   3. server.jks
   4. server.key
   5. server.p12

Integrate It with Mule and Deploy Server Application

1. Create a new application in Mule.
   
2. Drag and drop an HTTP listener, set the protocol as HTTPS, and add the JKS file which we have created in the previous step.Note: I have not included any trust store because we have not setup any client until now. We will see in the next step.
3. Add a Set Payload and run it locally.
   
4. You can check the certificate details

Create Client Setup

1. Perform the same step as we did for the server setup. But this would be on the client end.
   You will have the below files generated for the client:
   1. client.crt
   2. client.csr
   3. client.jks
   4. client.key
   5. client.p12

Import Client Public certificate(.crt) to Server Truststore

In order to access the server API, we need to request serve to add client public certificate(client.crt) to server truststore. If we miss this step we will get SSL Handshake failure. Please follow the below command to add client public certificate to truststore and deploy that application on cloudhub/onprem.

1. Import client.crt to server truststore.
   keytool -import -alias client-cert -keystore client-truststore.jks -file client.crt
2. Import the truststore to your demo-server API and deploy it on Cloudhub/Onprem.
   The application will get deployed and if you try to hit the endpoint you will get an error as SSL handshake error: null cert chain. This is because you are trying to hit it directly and not using client certificate.
3. Create a demo-client application and try to consume server payload
   
4. Add HTTP listener and HTTP request (which points to your demo-server)
5. Add client keystore to HTTP request, so server can validate and allow access to client.
6. Since we have already added client public certificate to server keystore. It will provide a response from server.
   

Import Server Public certificate(.crt) to the Client truststore:

This demonstrates one-way SSL as it only shares the client public certificate to server. To achieve two-way SSL, add the server public certificate to client truststore. Perform the below steps:

1. Generate truststore from server.crt
   keytool -import -alias server-cert -keystore server-truststore.jks -file server.crt
2. Add server-truststore.jks to truststore of demo-client
   
3. Once you add the truststore, deploy your project locally to test the connectivity.
   

This is how two-way SSL works. In real-world case scenarios we only do configuration either on the server-side or client-side. I hope this example would help you to configure two-way SSL.

Self-Signed SSL Certificate Is Much Risky & Costlier Compared to Trusted Certificate Authorities

Everyone likes to save money by reducing costs. Those smart companies and businesses that spend a huge amount of money on their infrastructure and other things are no different. Though security is not something, they’d think about reducing the cost, when it comes to trimming down overall expenses. However, in last but some IT security professionals do believe that costs of security can be lowered down by eliminating third-party SSL/TLS Certificate issued by Certificate Authorities.

However, this belief system can backfire – badly, mainly because the total cost of an SSL/TLS certificate is beyond its price. From a security point of view – technical as well as business, the do it yourself approach towards an SSL/TLS certificate may put your organization at risk in many different ways.

Risk of Using Self-Signed SSL/TLS Certificate Used on Publicly Facing Sites

From technical point organizations that use a Self-signed SSL certificate tell browsers such as Google Chrome or Mozilla Firefox that “I verify that I am myself. Trust me.” and as per the standards of these popular web browsers, it’s meaningless.

If you used this, the user who tries accessing your website would also face an error message saying the signing entity is not trustworthy. It’s unknown, resulting in damage to brand reputation, loss of customer trust, the decline of conversions, and website visitors.

Risks Involved With Self-Signed SSL/TLS Certificate Used on Internal Sites

Corporate email servers, wikis for individual project management, software development sandboxes, and human resource (HR) portals are some of the internal sites and servers examples where SSL/TLS certificate is used often.

Nevertheless, risks are involved in using a self-signed SSL/TLS certificate with publicly facing websites, but risks with internal websites are not less. Many times employees simply ignore the warning message faced while opening any internal site, but it can result in similar behavior towards publicly facing websites as well. If they get accustomed, they may even ignore warning messages on public sites and leaving your organization open to malware and other similar cyber threats.

Let us assume that I have two computers:

• client
• server

Now, in the server computer, I set up a legacy ASMX web service which will going to be used by the client. Before the client can connect to to the web service, however, I want him to be authenticated using digital certificates.

So I do the following:

1. Create a self-signed certificate on the server (certification authority)
2. Install the certificate in the Trusted Root Certification Authorities on the server (through MMC).
3. Install the certificate in the Trusted Root Certification Authorities on the client (through MMC).
4. Generate a certificate (based on the self-signed certificate) for the web service application and install it in the Personal certificates section (through MMC) on the server machine.
5. Generate a certificate (based on the self-signed certificate) for the client and install it in the Personal certificates section (through MMC) on the client machine.
6. When the client communicates with the server using the web service, the two entities exchange certificates for authentication.

Is the procedure highlighted above correct? I am asking this because I found a lot of articles overloaded with information and which fail to describe the basics in a simple manner.

1 Answer 1

Your principles are correct, but the particulars can be a devil to set right.

Indeed, the general schema is that:

The client needs to validate the certificate from the server, i.e. verify that the certificate has been issued (signed) by a trusted CA, and that the alleged server certificate contains the name of the server.

Similarly, the server needs to validate the certificate from the client, i.e. verify that the certificate has been issued (signed) by a trusted CA, and then obtain the “client name” from the certificate.

So both client and server need to trust some root CA certificate — not necessarily the same (but it does not hurt that they both trust the same). Moreover, both client and server can be a bit picky about what they find in their own certificate, and in the certificate from the peer. The server certificate will have to contain the server name as prescribed by RFC 2818 (section 3.1). If you include the Extended Key Usage extension, then IIS and Internet Explorer will tend to require the “server authentication” key usage (1.3.6.1.5.5.7.3.1). For the client certificate, IE and IIS will again want to see a specific key usage, namely “client authentication” (1.3.6.1.5.5.7.3.2).

The server (IIS) must also make something out of what it finds in the client certificate. There are several methods. “Account mapping” is about associating the client certificate with a client account, accounts being the notion of identity which prevails within a Windows operating system. If an Active Directory domain is in force, the mapping can be direct (the certificate is mapped to the account which, on the AD server, contains a copy of the certificate) or indirect (the certificate contains a copy of the User Principal Name of the account, in its Subject Alt Name extension). Non-mapped authentication is possible, too, in which case the application is responsible for making sense of the certificate.

Certificate revocation can be a problem, too. Conceptually, a CA who has issued a certificate can “express remorse”, and announce to the World at large that a given certificate, though seemingly all signed and signed and valid, must nonetheless be rejected. This supports emergency situations such as a stolen private key. This announcement uses a Certificate Revocation List, a short-lived object signed by the CA. Both the server and the client may want to obtain a fresh CRL which covers the certificate they are trying to validate. Your homemade PKI does not publish CRL regularly, so if the client or the server gets into its head to verify revocation status, things will fail.

Whether IIS and/or IE will engage into revocation check depends on what they find in the certificates, but that’s not documented with the utmost clarity. IIS can be configured to disregard revocation checks. For Internet Explorer, this can also be done, apparently on a zone basis (IE categorizes servers in “zones”, such as “local intranet” or “Internet”, and can apply different security settings for each zone, one of which being “enforce revocation status check”).

Securing your Java application with an SSL certificate can be extremely important. Fortunately, it is (usually) quite simple to do using Java Keytool. Most situations require that you buy a trusted certificate, but there are many cases when you can generate and use a self signed certificate for free.

When to Use a Keytool Self Signed Certificate

An SSL certificate serves two essential purposes: distributing the public key and verifying the identity of the server so users know they aren’t sending their information to the wrong server. It can only properly verify the identity of the server when it is signed by a trusted third party. A self signed certificate is a certificate that is signed by itself rather than a trusted authority. Since any attacker can create a self signed certificate and launch a man-in-the-middle attack, a user can’t know whether they are sending their encrypted information to the server or an attacker. Because of this, you will almost never want to use a self signed certificate on a public Java server that requires anonymous visitors to connect to your site. However, self signed certificates have their place:

Never use a self signed certificate on an e-commerce site or any site that transfers valuable personal information like credit cards, social security numbers, etc.

• An Intranet. When clients only have to go through a local Intranet to get to the server, there is virtually no chance of a man-in-the-middle attack.
• A Java development server. There is no need to spend extra cash buying a trusted certificate when you are just developing or testing an application.
• Personal sites with few visitors. If you have a small personal site that transfers non-critical information, there is very little incentive for someone to attack the connection.

Just keep in mind that visitors will see a warning in their browsers (like the one below) when connecting to a server that uses a self signed certificate until it is permanently stored in their certificate store.

Generate a Self Signed Certificate using Java Keytool

Now that you know when to use a Keytool self signed certificate, let’s create one using a simple Java Keytool command:

1. Open the command console on whatever operating system you are using and navigate to the directory where keytool.exe is located (usually where the JRE is located, e.g. c:\Program Files\Java\jre6\bin on Windows machines).
2. Run the following command (where validity is the number of days before the certificate will expire):
   keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
3. Fill in the prompts for your organization information. When it asks for your first and last name, enter the domain name of the server that users will be entering to connect to your application (e.g. )

This will create a keystore.jks file containing a private key and your sparklingly fresh self signed certificate. Now you just need to configure your Java application to use the .jks file. If you are using Tomcat, you can follow our Tomcat SSL Installation Instructions.

For more information on creating a Java Keytool Self Signed Certificate, see the following links:

Originally posted on Sat Oct 30, 2010

Last updated February 03, 2021

Check out Automated Certificate Management to see if it meets your needs before going further in this article.

When using the SSL for non-production applications or other experiments you can use a self-signed SSL certificate. Though the certificate implements full encryption, visitors to your site will see a browser warning indicating that the certificate should not be trusted.

For apps with controlled distribution this warning can be avoided by creating your own authority certificate and adding it to your users’ browsers.

Prerequisites

The openssl library is required to generate your own certificate. Run the following command in your local environment to see if you already have openssl installed installed.

If the which command does not return a path then you will need to install openssl yourself:

Generate private key and certificate signing request

A private key and certificate signing request are required to create an SSL certificate. These can be generated with a few simple commands.

When the openssl req command asks for a “challenge password”, just press return, leaving the password empty. This password is used by Certificate Authorities to authenticate the certificate owner when they want to revoke their certificate. Since this is a self-signed certificate, there’s no way to revoke it via CRL (Certificate Revocation List).

More detailed instructions can be found in Creating an SSL Certificate Signing Request.

You can secure an application running on Kubernetes by creating a secret that contains a TLS (Transport Layer Security) private key and certificate.

Currently, Ingress supports a single TLS port, 443, and assumes TLS termination.

The TLS secret must contain keys named tls. crt and tls. keys that contain the certificate and private key to use for TLS.

Create TLS Secret:

Using YAML file:

Ingress with TLS:

Self Signed Certificate

A self-signed SSL certificate is an SSL Certificate that is issued by the person creating it rather than a trusted certificate authority. This can be good for testing environments.

Step 1: Generate a CA private key

Step 2: Create a self-signed certificate, valid for 365 days.

Step 3: Now, create the tls secret using the kubectl command or using the yaml definition.

Check the secret.

Describe the secret.

Drawbacks of Self-signed Certificate:

Self-signed shows untrusted connection warning while connecting to HTTPS website. Thus, the Self-Signed certificate is not the right choice for online businesses

A self-signed certificate does lack authenticity hence, attackers can replace the self-signed certificate with the attacker’s certificate. However, browsers will have no idea whether it is communicating with the right SSL certificate or a replaced certificate.

Third-party CAs offer warrants against certain losses in the case of certificate is-issuance. A self-signed certificate does not endow with warranty protection.

Customer scared to deal with a self-signed certificate because of the unsafe environment of the certificate while customer gains self-assurance transacting online with a signed certificate.

How to do TLS between microservices in Kubernetes?

Kubernetes Services and DNS Discovery
In general, it is recommended to put a Service in front of a Deployment that manages pods in Kubernetes. The Service creates a stable DNS and IP endpoint for pods that may be deleted and be assigned a different IP address when recreated. DNS service discovery is automatically enabled with a ClusterIP type service and is in the format: . .svc. where cluster domain is usually cluster.local. This means that we can use the auto-created DNS and assigned ClusterIP in our alt names for our certificate.

Kubernetes Internal CA
Kubernetes does have an internal CA along with API methods to post CSRs and have those CSRs signed by the CA however I would not use the internal CA for securing microservices. The internal CA is primarily used by the kubelet and other internal cluster processes to authenticate to the Kubernetes API server. There is no functionality for autorenewal and I think the cert will always be signed for 30 days.

Kubernetes-native Certificate Management
You can install and use cert-manager to have the cluster automatically create and manage certificates for you using custom resources. They have excellent examples on their website so I would encourage you to check that out if it is of interest. You should be able to use the CA Issuer Type and create Certificate Resources that will create a certificate as a Kubernetes Secret. For the alt names, refer to the below certificate generation steps in the manual section of my response.

Manually Create and Deploy Certificates

You should be able to achieve the same result using your “without Kubernetes” approach using cfssl:

generate CA using cfssl

add CA as trusted in the image (using your Dockerfile approach)

create Kubernetes Service (for example purposes I will use kubectl create)

$ kubectl create service clusterip grpcserver — tcp=8000
describe the created Kubernetes Service, note IP will most likely be different in your case