TL;DR: The "unable to verify the first certificate" error in MCP mail server occurs when Node.js cannot validate the server's TLS certificate chain. Setting NODE_EXTRA_CA_CERTS often fails because the environment variable is read at process start, not during runtime, or because the certificate chain is incomplete. The fix: ensure the full certificate chain (including intermediates) is correctly concatenated and that the environment variable is set before the Node process launches.

What happens when your MCP mail server suddenly rejects every connection?

You've just deployed your MCP mail server – maybe it's a custom SMTP relay or an IMAP bridge for your AI agent. Everything works in development. But in production, your logs fill with a single, maddening error:

Error: unable to verify the first certificate
    at TLSSocket.onConnectSecure (_tls_wrap.js:1502:34)
    at TLSSocket.emit (events.js:315:20)
    at TLSSocket._finishInit (_tls_wrap.js:937:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:711:12)

You scramble. You set NODE_EXTRA_CA_CERTS to point at your CA bundle. You restart the server. Nothing changes. The error persists. Your AI agent can't send or receive mail, and your workflow is dead in the water.

I've seen this exact scenario play out across dozens of teams – from solo developers running n8n workflows to enterprise automation architects managing multi-node MCP deployments. The fix is rarely what you expect.

Why this keeps happening

The error "unable to verify the first certificate" is Node.js's way of saying: "I received a certificate, but I can't trace it back to a trusted root." This happens for three distinct reasons, and understanding which one you're dealing with is the key to fixing it.

Root cause 1: Missing intermediate certificates

Most TLS certificate chains include three parts: the server certificate, one or more intermediate certificates, and the root certificate. When a server sends only its server certificate during the TLS handshake, Node.js cannot build the chain to a trusted root. The "first certificate" it refers to is the server certificate – it's the first one in the chain, and Node.js can't verify it because it has no intermediates to connect it to a root.

Root cause 2: NODE_EXTRA_CA_CERTS timing

NODE_EXTRA_CA_CERTS is an environment variable that Node.js reads exactly once – when the process starts. If you set it after the process is already running (e.g., in a shell script that launches the server but sets the variable in the wrong order), it has zero effect. This is the most common reason the variable "doesn't work."

Root cause 3: Incorrect certificate format

Node.js expects PEM-encoded certificates in the bundle file. If your CA bundle contains DER-encoded certificates, or if there are extra whitespace characters, or if the file has a BOM (Byte Order Mark), Node.js will silently ignore the certificates, and the error persists.

The solution: Build a complete certificate chain and set the variable correctly

The fix has two parts: ensuring the certificate chain is complete and correctly formatted, and ensuring NODE_EXTRA_CA_CERTS is set before the Node process starts.

Step-by-step implementation

Step 1: Identify the missing certificates

First, determine what certificates your server is sending. Use OpenSSL to inspect the server's TLS handshake:

openssl s_client -connect mail.example.com:465 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout 2>/dev/null | grep "Subject:"

If you see only one certificate returned, you're missing intermediates. Run the full handshake dump:

openssl s_client -connect mail.example.com:465 -showcerts </dev/null

Look for the ---BEGIN CERTIFICATE--- blocks. Each block is a certificate in the chain. If there's only one, you need to add the intermediates.

Step 2: Download the missing intermediate certificates

Find the Certificate Authority (CA) that issued your server certificate. Common CAs include Let's Encrypt, DigiCert, Sectigo, and GlobalSign. Download the intermediate certificate bundle from the CA's website.

For example, for Let's Encrypt:

curl -O https://letsencrypt.org/certs/lets-encrypt-r3.pem
curl -O https://letsencrypt.org/certs/isrgrootx1.pem

Step 3: Create a complete CA bundle

Concatenate the certificates in order: server certificate first, then intermediates, then root. This is critical – the order matters.

cat /path/to/server-cert.pem /path/to/intermediate.pem /path/to/root.pem > /etc/ssl/certs/mcp-mail-ca-bundle.pem

Ensure the file is PEM-encoded (starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE----- for each certificate).

Step 4: Set NODE_EXTRA_CA_CERTS correctly

Set the environment variable before starting your Node process. The safest way is to export it in the same command:

export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/mcp-mail-ca-bundle.pem && node your-mcp-server.js

Or in a systemd service file:

[Service]
Environment="NODE_EXTRA_CA_CERTS=/etc/ssl/certs/mcp-mail-ca-bundle.pem"
ExecStart=/usr/bin/node /opt/mcp-mail-server/index.js

Step 5: Verify the fix

Test the connection again:

node -e "const tls = require('tls'); const socket = tls.connect(465, 'mail.example.com', {rejectUnauthorized: true}, () => { console.log('Connected successfully'); socket.end(); }); socket.on('error', (err) => console.error('Error:', err.message));"

If you see "Connected successfully," you're done.

If that doesn't work, try...

If the error persists, check these alternatives:

• Use NODE_TLS_REJECT_UNAUTHORIZED=0 as a temporary workaround – but only for testing. This disables all certificate validation and is a security risk. Never use in production.
• Check for self-signed certificates: If your mail server uses a self-signed certificate, you need to add that certificate itself to the bundle, not a CA chain.
• Verify the file path: Ensure the path in NODE_EXTRA_CA_CERTS is absolute and the file is readable by the Node process user. Run ls -la /path/to/bundle.pem to confirm.

Real-world example

Sarah, a workflow automation engineer at a mid-sized logistics company, was building an MCP-based email agent to automatically process shipping confirmations. Her setup used n8n with a custom MCP mail server connecting to their corporate Exchange server via SMTP over TLS.

Every time the workflow triggered, the MCP server logged the "unable to verify the first certificate" error. She set NODE_EXTRA_CA_CERTS in her Docker Compose file, rebuilt the container, and the error persisted.

After two hours of debugging, she discovered two issues:

1. The corporate Exchange server was sending only its server certificate during the TLS handshake, omitting the internal CA's intermediate certificate.
2. Her Docker Compose file set NODE_EXTRA_CA_CERTS in the environment section, but the Node process inside the container was started by a shell script that didn't inherit the environment variable correctly.

She downloaded the internal CA's intermediate certificate from the IT team, concatenated it with the root certificate into a single PEM file, and mounted it into the container. She then modified the Docker entrypoint to explicitly export the variable before starting Node:

ENTRYPOINT ["sh", "-c", "export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-bundle.pem && node /app/server.js"]

The error disappeared, and her email agent processed 12,000 shipping confirmations in the first week without a single TLS failure.

Prevention

To avoid hitting this error in the future:

1. Always test with a full certificate chain from the start. When setting up a new MCP mail server, verify the server's TLS configuration using openssl s_client before writing any code. If the chain is incomplete, fix it at the server level first.

2. Set NODE_EXTRA_CA_CERTS in the process launcher, not in a shell profile. Whether you use systemd, Docker, or a simple shell script, ensure the variable is set in the same command that starts Node. Never rely on .bashrc or .profile – they may not be sourced in non-interactive shells.

3. Use a certificate validation tool in your CI/CD pipeline. Add a step that tests TLS connectivity before deployment. Tools like ssl-cert-check or a simple Node.js script can catch missing intermediates early.

4. Document your certificate chain. Maintain a file that lists every certificate in your chain, its issuer, and its expiration date. This makes debugging future TLS issues trivial.

Related errors

You might also encounter these similar errors:

• "self-signed certificate in certificate chain" – The server presented a self-signed certificate that isn't in your trusted store. Add the self-signed cert to your bundle.
• "certificate has expired" – The server certificate or an intermediate has passed its expiration date. Renew the certificate.
• "hostname mismatch" – The certificate's Common Name (CN) or Subject Alternative Name (SAN) doesn't match the hostname you're connecting to. Verify the server's DNS name matches the certificate.
• "unable to get local issuer certificate" – Node.js cannot find the issuer certificate for the server's certificate. This is essentially the same root cause as the "first certificate" error but with a different message depending on the Node.js version.
• "DEPTH_ZERO_SELF_SIGNED_CERT" – The server presented a self-signed certificate at depth 0 (the server certificate itself). This is common in development environments.

Conclusion

The "unable to verify the first certificate" error in MCP mail server is frustrating because it seems like NODE_EXTRA_CA_CERTS should fix it – but it only works when the certificate chain is complete and the environment variable is set correctly. By understanding the TLS handshake and Node.js's certificate loading behavior, you can resolve this error in minutes rather than hours.

For more troubleshooting guides and ready-to-use MCP workflow templates on Neura Market, visit the Neura Market troubleshooting section.

Frequently Asked Questions

What is the best way to get started with How to Fix "unable to verify the first c?

The best approach is to start with a clear goal in mind. Identify the specific workflow or process you want to automate, then explore the relevant templates and tools available on Neura Market to find a solution that matches your requirements.

How much does workflow automation typically cost?

Costs vary significantly depending on the platform and scale. Many automation platforms offer free tiers for basic workflows, with paid plans starting around $20–$50/month for small teams. Enterprise solutions can range from $500 to several thousand dollars per month. Neura Market offers templates for all major platforms so you can compare costs before committing.

Do I need technical skills to implement workflow automation?

Modern no-code and low-code platforms like Zapier, Make.com, and others have made automation accessible to non-technical users. Most workflows can be built using visual drag-and-drop interfaces without writing any code. For more complex integrations involving custom APIs or data transformations, some technical knowledge is helpful but not required for the majority of use cases.