mTLS in OneEntry: When Security Is Not an Option but a Standard

In today’s web environment, APIs are not just data transmission channels. They function as the nervous system of any digital business. Ensuring the security of such a critical part of business infrastructure is not a secondary concern, but a strategic priority. OneEntry Headless CMS was the first on the market to implement full support for mutual TLS (mTLS) within its platform, one of the most reliable technologies for API protection available today. The primary motivation behind this decision was to address real-world challenges faced by web and mobile development teams, DevOps engineers, and, ultimately, the digital businesses they support. Why Your Business Needs mTLS: Not Theory, but Reality As we know, cyber threats don’t target some abstract concept of “security”. They go after what has real value: Personal customer data: the leakage of emails, phone numbers, and payment details inevitably leads to fines, lawsuits, and, as a result, damage to an application’s reputation. Authentication data: logins, passwords, API tokens. The capture of this information compromises services and also causes financial losses for digital businesses. Commercial information: customer databases, deals, pricing, proposals. This is the foundation of competitive advantage, and its interception can be used as a weapon in unfair competition for market share. This is precisely where mutual TLS comes into play — a protocol for mutual authentication in which the server and client confirm each other’s identity through certificates. Unlike tokens, mTLS not only provides authentication, but also eliminates the risk of unauthorized access at the network level. It is a reliable layer of protection for both businesses and digital services against all the threats listed above. What mTLS Brings to Real-World Projects Access restricted to trusted services. Only applications and microservices with valid certificates are allowed to connect to the API. This is especially important in distributed architectures where it’s critical to know exactly who is making the request and from where. Protection against traffic interception and spoofing. A token can be stolen. A certificate cannot, unless the private key is compromised. Security at the DevOps level. Integration with CI/CD tools (such as GitHub Actions or GitLab CI) makes it possible to deploy applications securely and pass certificates through environment variables without storing them in code. Flexible configuration for different environments. You can issue separate certificates for different clients, integrations, and environments (such as production, test, or staging). This enables precise control over API access in each specific context. Now that the core features of mTLS and its benefits for API security are clear, it’s time to explore how this technology is implemented in practice with OneEntry. The platform provides all the necessary tools for quickly setting up a secure communication channel between your application and the API, while meeting modern standards for DevOps, infrastructure, and security. Implementing mTLS in OneEntry To configure secure communication using mutual TLS (mTLS) in OneEntry, you need to follow a sequence of steps — from selecting the authorization method to configuring the server environment and CI/CD processes. Step 1. Switching from token to mTLS In the OneEntry admin panel: Open the Access tab and select the mTLS mode. In the Settings → Application Certificates section, create a new certificate. Download the certificate archive and unpack it into the cert folder at the root of your project. Example folder structure: project-root/ ├── cert/ │ ├── client.crt │ └── client.key Step 2. Local configuration for ReactJS Create a file named setupProxy.js inside the src folder: const { createProxyMiddleware } = require('http-proxy-middleware'); module.exports = function(app) { app.use( '/api', createProxyMiddleware({ target: 'https://your-domain.com', secure: true, changeOrigin: true, ssl: { cert: fs.readFileSync('cert/client.crt'), key: fs.readFileSync('cert/client.key') } }) ); }; Install the dependency: npm install http-proxy-middleware Step 3. Server configuration (Docker, Nginx, Certbot) UFW and SSH configuration: sudo ufw default deny incoming sudo ufw allow 22,80,443/tcp sudo ufw enable sudo nano /etc/ssh/sshd_config # Set PasswordAuthentication no sudo systemctl restart ssh Nginx configuration: server { listen 443 ssl; server_name your-domain.com; ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; location / { proxy_pass https://localhost:3000; proxy_ssl_certificate /path/to/client.crt; proxy_ssl_certificate_key /path/to/client.key; } } Obtaining ce

May 15, 2025 - 20:24

mTLS in OneEntry: When Security Is Not an Option but a Standard

In today’s web environment, APIs are not just data transmission channels. They function as the nervous system of any digital business. Ensuring the security of such a critical part of business infrastructure is not a secondary concern, but a strategic priority.

OneEntry Headless CMS was the first on the market to implement full support for mutual TLS (mTLS) within its platform, one of the most reliable technologies for API protection available today. The primary motivation behind this decision was to address real-world challenges faced by web and mobile development teams, DevOps engineers, and, ultimately, the digital businesses they support.

Why Your Business Needs mTLS: Not Theory, but Reality

As we know, cyber threats don’t target some abstract concept of “security”. They go after what has real value:

Personal customer data: the leakage of emails, phone numbers, and payment details inevitably leads to fines, lawsuits, and, as a result, damage to an application’s reputation.

Authentication data: logins, passwords, API tokens. The capture of this information compromises services and also causes financial losses for digital businesses.

Commercial information: customer databases, deals, pricing, proposals. This is the foundation of competitive advantage, and its interception can be used as a weapon in unfair competition for market share.

This is precisely where mutual TLS comes into play — a protocol for mutual authentication in which the server and client confirm each other’s identity through certificates. Unlike tokens, mTLS not only provides authentication, but also eliminates the risk of unauthorized access at the network level. It is a reliable layer of protection for both businesses and digital services against all the threats listed above.

What mTLS Brings to Real-World Projects

Access restricted to trusted services. Only applications and microservices with valid certificates are allowed to connect to the API. This is especially important in distributed architectures where it’s critical to know exactly who is making the request and from where.
Protection against traffic interception and spoofing. A token can be stolen. A certificate cannot, unless the private key is compromised.
Security at the DevOps level. Integration with CI/CD tools (such as GitHub Actions or GitLab CI) makes it possible to deploy applications securely and pass certificates through environment variables without storing them in code.
Flexible configuration for different environments. You can issue separate certificates for different clients, integrations, and environments (such as production, test, or staging). This enables precise control over API access in each specific context.

Now that the core features of mTLS and its benefits for API security are clear, it’s time to explore how this technology is implemented in practice with OneEntry. The platform provides all the necessary tools for quickly setting up a secure communication channel between your application and the API, while meeting modern standards for DevOps, infrastructure, and security.

Implementing mTLS in OneEntry

To configure secure communication using mutual TLS (mTLS) in OneEntry, you need to follow a sequence of steps — from selecting the authorization method to configuring the server environment and CI/CD processes.

Step 1. Switching from token to mTLS

In the OneEntry admin panel:

Open the Access tab and select the mTLS mode.
In the Settings → Application Certificates section, create a new certificate.
Download the certificate archive and unpack it into the cert folder at the root of your project.

Example folder structure:

project-root/
├── cert/
│   ├── client.crt
│   └── client.key

Step 2. Local configuration for ReactJS

Create a file named setupProxy.js inside the src folder:

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function(app) {
  app.use(
    '/api',
    createProxyMiddleware({
      target: 'https://your-domain.com',
      secure: true,
      changeOrigin: true,
      ssl: {
        cert: fs.readFileSync('cert/client.crt'),
        key: fs.readFileSync('cert/client.key')
      }
    })
  );
};

Install the dependency:

npm install http-proxy-middleware

Step 3. Server configuration (Docker, Nginx, Certbot)

UFW and SSH configuration:

sudo ufw default deny incoming
sudo ufw allow 22,80,443/tcp
sudo ufw enable

sudo nano /etc/ssh/sshd_config
# Set PasswordAuthentication no
sudo systemctl restart ssh

Nginx configuration:

server {
  listen 443 ssl;
  server_name your-domain.com;

  ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;

  location / {
    proxy_pass https://localhost:3000;
    proxy_ssl_certificate /path/to/client.crt;
    proxy_ssl_certificate_key /path/to/client.key;
  }
}

Obtaining certificates:

sudo certbot certonly --webroot -w /var/www/html -d your-domain.com

Step 4. Configuring GitHub Runner

Creating and configuring a user:

pwgen -s 15 1
useradd -m github-runner
usermod -aG docker,sudo github-runner
chsh -s /bin/bash github-runner
sudo su - github-runner

Starting the Runner:

./svc.sh install
./svc.sh start

Step 5. Configuring GitLab Runner

Docker Compose configuration for the Runner:

version: '3'
services:
  runner:
    image: 'gitlab/gitlab-runner:v16.2.0'
    privileged: true
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
      - './volumes/etc/gitlab-runner:/etc/gitlab-runner'

Editing config.toml:

privileged = true
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
user = "gitlab-runner"

Registering the Runner:

docker compose run runner register

Testing and Final Verification

After completing all setup steps, it is recommended to perform a final check:

Make sure the pipelines in GitHub and GitLab are running correctly.
Verify that the application is accessible via a secure HTTPS address and is operating through an mTLS connection.

Comparison of mTLS with Other API Protection Methods

To objectively assess the reliability of mTLS, it is important to consider it in the context of other commonly used API protection methods such as OAuth, API tokens, and JWT. Below is a brief comparative overview:

OAuth is effective for end-user authorization. However, in server-to-server interactions, it is less reliable due to potential risks of token interception.
API tokens are simple to implement but are vulnerable to spoofing and do not provide mutual authentication between parties.
JWT (JSON Web Token) is widely used, but it requires additional mechanisms to protect against compromise and token interception.

As mentioned earlier, mTLS provides two-way authentication, offers strong protection against spoofing and data interception, and significantly enhances overall security. It demonstrates the highest level of protection among the methods listed and is the optimal choice for projects where security is critical, especially when handling confidential data and internal APIs.

Why mTLS Support Is Especially Important for Businesses in the SME Segment

Mid-sized businesses around the world, just like large enterprises, face serious risks related to API security and data protection. However, unlike major players with substantial resources to manage incidents and restore reputation, companies in the SME segment are often far more vulnerable. A single data breach or targeted attack can have critical consequences and even threaten the company’s continued existence.

In such conditions, implementing mTLS becomes not just a technological enhancement but a necessary step toward resilience and risk reduction. Protection based on mutual authentication between client and server ensures that data is exchanged strictly between trusted parties and cannot be intercepted or altered.

OneEntry is the only Headless CMS that offers mutual TLS support by default, available right out of the box. This solution allows businesses not only to enhance security, but also to significantly reduce resources spent on implementation and ongoing maintenance, eliminating the need for manual security configuration.

The ability to enable robust protection without additional integrations, while still complying with modern security requirements, was a foundational goal of our solution. We want our clients to grow their projects and succeed, supported by a platform that offers the technological stability and trust they can rely on.