Tech Mastery: Deep Dives into AEM, Cloud Technologies, AI Innovations, and Advanced Marketing Strate

Most of the time, web developers need help understanding the basics of SSL certificate management, the SSL management may be taken care of by separate admin teams but understanding the basics helps them to manage the SSL process quickly. In this post, I will discuss the SSL certificate management basics that help Web Developers understand the SSL management process and help them in their work.

What is an SSL certificate?

An SSL (Secure Sockets Layer) certificate is a digital certificate that authenticates the identity of a website and encrypts information sent to the server using SSL technology. When a user attempts to send confidential information to a Web server, the user’s browser accesses the server’s digital certificate and establishes a secure connection. This is mandatory to enable an SSL certificate (HTTPS) when the website collects sensitive information from the users.

If the SSL certificate is enabled for a website, the website can be accessed through HTTPS (i.e., https://ww.albinsblog.com). The browsers help you determine if a website has an SSL certificate by displaying a small image of a lock by the URL.

SSL providers (CA):

SSL certificates are issued by Certificate Authorities (CAs), organizations that are trusted to verify the identity and legitimacy of any entity requesting a certificate. Before issuing a certificate, a certificate authority will examine the credentials of the person or organization that has asked for the certificate.

Multiple CAs issue SSL certificates, Digi Cert, Comodo, etc.; most are paid, but some free CAs (e.g., Lets Encrypt) are available.

Even you can create self-signed certificates for your local testing systems; Refer to How to Create Trusted Self-Signed SSL Certificates and Local Domains for Testing | by Albin Issac | Better Programming for more details on generating self-signed certificates through OpenSSL.

SSL Certificates Validation Levels:

There are three different types of SSL certificates based on the validation levels: domain validated (DV), organization validation (OV), and extended validation (EV). The one best suited for you will depend on your website and how much security you need.

DV SSL is best for personal project websites and is the least expensive option. It requires the website owner to verify that the domain is registered to the domain owner.

• Validates control of a domain
• Enables https and the padlock icon in browsers
• Issued quickly

The Organization (O) and Organization Unit (OU) fields both display “”
The Certificate Policies field shows an Object Identifier (OID) value of OID.2.23.140.1.2.1. Refer to Extensions -> validation Type → Certificate Polices from Certificate-Profiles.pdf (digicert.com) to identify the policies for different validation types.
The Subject field only contains a Common Name (CN) value with the domain, for example: CN=albinsblog.com.

OV SSL is best for business or nonprofit websites and requires a higher verification level, making it more secure. The SSL certificate issuer verifies the address and location of the owner.

• Validates control of the domain
• Enables https and the padlock image
• Authenticates the legitimacy of an organization, adding a level of trust
• Shows organization details in the certificate information
• Issued in 1–3 days

The Organization (O) field displays your organization’s name.
The Subject field includes information about the organization’s location (L), state (ST), and country(C), in addition to the organization (O) and common name (CN).
The Certificate Policies field shows an OID value of OID.2.23.140.1.2.2.

EV SSL is best for e-commerce businesses and businesses exchanging financial data as it offers the most protection. In addition, these certificates provide the highest monetary warranties to any website viewers affected by an SSL failure.

• Validates control of the domain
• Enables https and the padlock image
• Authenticates the legitimacy of an organization, adding a level of trust
• Verifies the applicant has the right to request an EV SSL and is in good standing with the organization.
• Shows organization details in the certificate information
• Issued in 1–5 days

The Organization (O) field displays your organization’s name.
The Subject field includes details about the organization’s location (L), state (ST), and country(C), the organization (O) and common name (CN), additionally serialNumber, jurisdictionStateOrProvinceName and jurisdictionCountryName
The Certificate Policies field shows an OID value of OID.2.23.140.1.1.

The green bar that used to be activated for EV certificates has now been removed from most web browsers; the EV certificate will display the Organization details (as displayed for OV certificates), but no green bar is activated, but still, the EV certificate provides the additional trust.

Validates control of a domain:

Before the certificate authority can issue an SSL certificate, the certificate applicant needs to confirm their domain ownership rights. To give the SSL certificate as a first step, the Domain should be validated by following the methods defined by the Certificate authority. There are multiple validation methods; you should follow the appropriate way to prove the Domain ownership.

• Verification Email — receive the verifying email to the email contact specified on the WHOIS record.
• DNS CNAME Record — Add a specific CNAME record generated by the CA to the domain zone.
• DNS TXT Record — Add a specific TXT record generated by the CA to the domain zone.
• HTTP Practical Demonstration — upload the validation file to your host

Type of SSL Certificates:

There are different types of SSL certificates issued

• Single Domain — As the name suggests, the single domain SSL certificate is an SSL/TLS certificate that secures only one fully qualified domain name (FQDN) per certificate.
• Wildcard SSL Certificates — the Wildcard SSL certificate secures a single domain and corresponding subdomains. The wildcard certificates are specified as *.albinsblog.com, covering albinsblog.com and all its subdomains (e.g., www.albinsblog.com).

• Multi-Domain Certificates — Multi-domain SSL certificates are for safeguarding multiple domains. These multi-domain SSL certificates are also commonly known as Subject Alternative Names or SAN. If you have an environment with multiple domains/subdomains, you must buy multi-domain SSL certificates covering all the individual domains/subdomains. Even future domains can be added to the existing multi-domain certificate.

• Multi-Domain Wildcard — The multi-domain Wildcard SSL certificate combines the features of both the multi-domain and the Wildcard SSL certificates. In other words, with a single certificate, you can secure multiple domains and all their related subdomains.

CSR (Certificate Signing Request)/Private Key:

A certificate signing request (CSR) is an encoded file containing information about your website, service, organization, and domain name. This information is used by a Certificate Authority (CA) to create an SSL/TLS certificate for your website to encrypt traffic to your site. A certificate CSR also contains your public key and signature, which helps to verify your identity and secure communications to your site.

All TLS certificates require a private key to work. The private key is a separate file used in the encryption/decryption of data sent between your server and the connecting clients. The certificate owner creates a private key when requesting the certificate with a Certificate Signing Request (CSR). The certificate authority (CA) providing your certificate (such as DigiCert) does not create or have your private key. No one outside your administrators should ever be given access to this material. The private key and the generated SSL certificate are configurated on the server to support secure communication.

Generate Private Key/CSR — there are multiple approaches to creating the private key and CSR request; a straightforward way is through OpenSSL.

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

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn

[dn]
C=US
ST=MN
L=Eagan
O=Tech Forum
OU=Marketing
emailAddress[email protected]
CN = example.com

openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key -config server.csr.cnf

This will generate server.csr and server.key (private key) files, request an SSL certificate from CA by sending(using) the CSR file generated.

After receiving the SSL certificate, configure the SSL certificate (need to configure the CAs intermediate and root certificate) along with the private key generated in the earlier steps — the configuration steps vary based on the SSL certificate’s location is installed.

In some cases, you may have a requirement to deploy the changes to a platform through a single repository/branch, e.g., AEM Cloud manager; AEM cloud manager supports a single repository and a branch to deploy the code changes to a specific environment — the containers are rebuilt on every deployment, so the complete code needs to be deployed on every deployment.

This can create restrictions while multiple teams working on different projects that all need to be deployed into the same platform; one approach is keeping all the project codes in a single repository, and all the teams can work on the same code repository, but sometimes this can lead into conflicts and dependencies between projects team.

Git submodules:

Git submodules can help to handle this scenario; Git submodules allow to merge of the content of multiple branches across repositories at build time. Git submodules help maintain complex projects by allowing independent repositories to exist as subdirectories within a wider project repository.

I have two maven projects in two different repositories; both repositories are enabled with the main branch

https://github.com/techforum-repo/project1.git
https://github.com/techforum-repo/project2.git

I have the main repository — https://github.com/techforum-repo/main-repository.git with the main branch

The below pom.xml enabled in the main-repository

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="https://maven.apache.org/POM/4.0.0" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://maven.apache.org/POM/4.0.0 https://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion><groupId>albin</groupId>
    <artifactId>main-repository</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>pom</packaging>    <modules>
        <module>project1</module>
        <module>project2</module>
    </modules></project>

Now add the submodule to the main repository by executing the below command on the main-repository folder

git submodule add -b main https://github.com/techforum-repo/project1.git project1
git submodule add -b main https://github.com/techforum-repo/project2.git project2

This will generate the .gitmodules file with the below content

[submodule "project1"]
 path = project1
 url = https://github.com/techforum-repo/project1.git
 branch = main
[submodule "project2"]
 path = project2
 url = https://github.com/techforum-repo/project2.git
 branch = main

The submodules are checked out under the main repository; now you can commit the submodule changes to the main-repository

git add .
git commit -m "Added the submodule to the project."
git push

Now the submodules are committed to the main-repository

To build the project.

Clone the Main Repository - git clone https://github.com/techforum-repo/main-repository.gitExecute - git submodule init && git submodule update

or

git clone --recurse-submodules https://github.com/techforum-repo/main-repository.git

Now build the main project (add the required parameters) — this will build the Sub Modules projects internally

mvn clean installmvn clean install -PautoInstallPackage -Daem.port=4503

Some of the Useful commands to manage Submodules

Update the Submodules in the main repository - git submodule update --remote

Update Specific Project - git submodule update --remote project2

Verify the status of the submodules - git submodule status

Show commit summary - git submodule summary

Run an arbitrary shell command in each checked-out submodule - git submodule foreache.g git submodule foreach 'echo $sm_path `git rev-parse HEAD`'

One of the concerns here is whenever the files from the Submodules (Project1 or Project2) are modified, the auto build through CI/CD pipeline will not be triggered as the build pipeline is configured to the main repository. The main repository will not be aware of the changes on the submodules.

This can be addressed by updating the submodules in the main repository with every change in the submodules (Project1 or Project2)

Execute the below commands on the main repository whenever there is a change on individual submodules, e.g., Project1, Project2 through a repository or external pipeline.git submodule update --remote
git add .
git commit -m "Sub Module Updated."
git push

To enable this in AEM Cloud Manager, create project-specific repositories in the Cloud Manager Program and create a main repository with the required submodules configurations. Enable the main repository to the pipelines so that all the required submodules will be deployed. You make the same repository structure in your source code management tool and enable the pipelines to sync the repository between your code repositories and Cloud Manager Repositories. Refer to https://betterprogramming.pub/a-bitbucket-ci-cd-pipeline-to-sync-branches-with-github-1c885cefe202 for details on syncing repositories.