Logging Monitoring Failures in Adonisjs with Mutual Tls

Mutual Transport Layer Security (mTLS) in AdonisJS adds a strong layer of identity verification by requiring both client and server to present valid certificates. When mTLS is combined with inadequate logging and monitoring practices, failures become harder to detect and investigate. The primary issue is not mTLS itself, but how AdonisJS applications record and surface events and errors in a mTLS-enabled environment.

Without sufficient logging around the mTLS handshake, you lose visibility into which client certificates were presented, whether they were validated successfully, and why a handshake might have failed. AdonisJS does not automatically log certificate details such as the subject, issuer, or serial number. If your application relies solely on framework-level request handling, you may not see mTLS-related failures in your central monitoring tools. This gap means brute-force or certificate-stuffing attempts can go unnoticed because failed handshakes are not captured as security events.

Additionally, errors that occur after a successful mTLS handshake—such as authorization failures, route mismatches, or runtime exceptions—can be misleading if contextual information like the certificate subject is missing from logs. Correlation becomes difficult when you cannot link a request to the identity expressed in the client certificate. Inadequate structured logging (e.g., missing request IDs or trace IDs) further fragments monitoring data, making it hard to trace a single transaction across services that all require mTLS.

Failures can also arise from misconfigured certificate validation within AdonisJS. For example, if the application does not properly enforce hostname verification or fails to validate certificate revocation via CRL or OCSP, an attacker could present a valid but compromised certificate. These issues may not cause crashes, but they create silent failures where access is granted incorrectly. Monitoring these subtle validation gaps requires explicit checks in your application code and observability pipelines that track validation outcomes.

To address these risks, ensure that every mTLS handshake attempt is logged with key metadata, including the request timestamp, client certificate subject and issuer, validation result, and any error codes. Combine this with structured logs and consistent trace identifiers so monitoring tools can aggregate and alert on mTLS-related anomalies. This approach turns mTLS from a blind gate into a monitored control with actionable telemetry.

Remediation focuses on explicit certificate handling, detailed logging, and robust monitoring within AdonisJS. You should configure the HTTPS server to require and validate client certificates, then enrich logs with certificate metadata to support monitoring and incident response.

Example: Configuring mTLS in AdonisJS

Below is a concrete example of setting up an mTLS-capable HTTPS server in an AdonisJS application using the built-in https module and AdonisJS provider hooks. This ensures the server requests and validates client certificates on each connection.

// start/server.js
const fs = require('fs');
const https = require('https');
const { Ignitor } = require('@adonisjs/ignitor');

const server = async () => {
  const httpsOptions = {
    key: fs.readFileSync('path/to/server-key.pem'),
    cert: fs.readFileSync('path/to/server-cert.pem'),
    ca: fs.readFileSync('path/to/ca-bundle.pem'),
    requestCert: true,
    rejectUnauthorized: true,
  };

  const app = await Ignitor
    .handle()
    .ignite()
    .server();

  const httpsServer = https.createServer(httpsOptions, app.callback());

  httpsServer.on('secureConnect', (tlsSocket) => {
    const cert = tlsSocket.getPeerCertificate();
    // Log certificate metadata for monitoring
    console.log({
      event: 'mtls_handshake',
      subject: cert.subjectName,
      issuer: cert.issuer,
      serialNumber: cert.serialNumber,
      valid: cert.valid_from <= Date.now() && cert.valid_to >= Date.now(),
    });
  });

  httpsServer.listen(443, () => {
    console.log('mTLS-enabled HTTPS server running on port 443');
  });
};

module.exports = server;

This configuration sets requestCert to true and rejectUnauthorized to true, which forces clients to present a certificate signed by the trusted CA. The secureConnect event gives access to the peer certificate, which you can log for monitoring purposes. Note that hostname verification is not performed by default in this snippet; you should add additional checks if needed.

Logging and Monitoring Hooks in AdonisJS

Integrate mTLS metadata into AdonisJS logging by using the request lifecycle. In your start/hooks.js or a dedicated middleware, capture certificate details and attach them to the log context.

// start/hooks.js
'use strict';

const { Application } = require('@adonisjs/fold');

module.exports = {
  async requestHook(request, response, next) {
    if (request.secure()) {
      const socket = request.socket;
      if (socket.authorized) {
        const cert = socket.getPeerCertificate();
        request.logContext = {
          mtls_subject: cert.subjectName,
          mtls_issuer: cert.issuer,
          mtls_serial: cert.serialNumber,
        };
      } else {
        request.logContext = {
          mtls_authorized: false,
          mtls_error: socket.authorizationError,
        };
      }
    }
    await next();
  },
};

With this hook, every request includes mTLS context in structured logs, which your monitoring system can index and alert on. You can then create dashboards that track failed authorizations, unexpected certificate issuers, or missing client certificates.

Remediation Summary

• Enforce rejectUnauthorized: true to ensure only valid client certificates are accepted.
• Log certificate metadata on handshake and attach it to request context for observability.
• Monitor for repeated handshake failures and authorization errors as indicators of attack or misconfiguration.