- 15 minutes to read

SSL/TLS Certificate Name Mismatch Errors

Note
Quick Navigation: Overview | SSL/TLS Certificate Revocation Errors | Office365 Email Issues

This FAQ addresses SSL/TLS certificate hostname mismatch errors when Nodinite attempts to send emails through SMTP servers. These errors occur when the hostname you connect to does not match any of the names listed in the server's SSL/TLS certificate, even when the "Ignore certificate revocation errors" option is enabled.

Problem

When testing or executing Email Alarm Plugins, you see errors similar to:

"MailKit.Security.SslHandshakeException: An error occurred while attempting to establish an SSL or TLS connection.
  • The remote certificate is invalid according to the validation procedure.
  • SSL policy error: RemoteCertificateNameMismatch
Inner Exception: The remote certificate was rejected by the provided RemoteCertificateValidationCallback."

Key indicators:

This error persists even after enabling the "Ignore certificate revocation errors" checkbox in Nodinite v7.2+
Intermittent errors: The "Execute Alarm test" button succeeds, but live alarms fail sporadically → See Intermittent Errors for DNS round-robin scenarios

Root Cause

The SSL/TLS certificate presented by your SMTP server does not include the hostname you specified in the Server field in its Subject Alternative Name (SAN) list.

Example Scenario (Anonymized):

You configure Nodinite to connect to smtp.example.com
The server at smtp.example.com presents a certificate whose SAN list only contains mail1.example.com and mail2.example.com
Result: Hostname mismatch → TLS handshake fails

Important
The "Ignore certificate revocation errors" option in Nodinite v7.2+ only bypasses revocation validation errors (CRL/OCSP checks). It does NOT bypass other SSL policy errors such as:

RemoteCertificateNameMismatch (hostname mismatch)

RemoteCertificateChainErrors (untrusted certificate authority)

RemoteCertificateNotAvailable (no certificate presented)

This is intentional for security reasons. Hostname verification prevents man-in-the-middle attacks and ensures you are connecting to the intended server.

Intermittent Errors (Test Succeeds, Live Alarms Fail)

Warning
Common Symptom: The "Execute Alarm test" button succeeds, but emails in the live alarm queue fail intermittently with RemoteCertificateNameMismatch errors.

Root Cause: DNS Round-Robin with Inconsistent Backend Certificates

The "Execute Alarm test" button and the live alarm queue use the same email sending logic, but there's a critical timing difference: the test sends immediately, while queued alarms retry in the background over time. This means they may hit different SMTP backend servers as DNS round-robin rotates through available IPs.

What's happening:

DNS Alias: smtp.example.com (and possibly smtp5.example.com) are DNS aliases in front of multiple SMTP nodes
Multiple Backend IPs: When you press the test button, DNS resolves to one IP and connects immediately
Round-Robin/Load Balancing: When the background service retries later, DNS may return a different IP whose certificate does NOT contain the alias you configured
Inconsistent Certificates: Some backend servers have certificates with smtp.example.com in the SAN list, while others only have mail.example.com or mail1.example.com

Important
Queued alarms retain their settings: If you update the SMTP server hostname in the Alarm Plugin configuration, existing queued emails still use the old (invalid) hostname. You must purge the alarm queue after changing SMTP settings to clear alarms with outdated configuration.

To purge the queue, navigate to Administration → Monitor Management → Alarm Queue and delete pending alarms with errors.

Example diagnostic approach:

Resolve-DnsName smtp.example.com | ForEach-Object {
    openssl s_client -connect "$($_. IPAddress):587" –starttls smtp –servername smtp.example.com
}

You will very likely find that only some nodes present a cert containing smtp.example.com, while others present a cert for mail.example.com or similar. When the queue lands on the latter, the handshake fails and the item stays queued.

How to Diagnose Intermittent Errors

Run this PowerShell script to check all backend servers:

<#
.SYNOPSIS
    Tests all backend servers behind a DNS alias for certificate consistency.
#>

param(
    [Parameter(Mandatory = $true)]
    [string]$HostName,  # The DNS alias (e.g., smtp.example.com)
    
    [Parameter(Mandatory = $false)]
    [int]$Port = 587
)

Write-Host "Resolving all IP addresses for $HostName..." -ForegroundColor Cyan
$ips = (Resolve-DnsName $HostName -Type A).IPAddress | Select-Object -Unique

Write-Host "Found $($ips.Count) unique IP address(es):`n" -ForegroundColor Yellow

$results = @()

foreach ($ip in $ips) {
    Write-Host "Checking certificate on $ip..." -ForegroundColor Cyan
    
    try {
        $tcp = New-Object System.Net.Sockets.TcpClient($ip, $Port)
        $ssl = New-Object System.Net.Security.SslStream(
            $tcp.GetStream(), 
            $false, 
            ({ param($sender, $certificate, $chain, $sslPolicyErrors) return $true })
        )
        
        # Authenticate using the ALIAS hostname (not the IP)
        $ssl.AuthenticateAsClient($HostName)
        
        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($ssl.RemoteCertificate)
        
        # Extract SAN list
        $san = $cert.Extensions | Where-Object { $_.Oid.FriendlyName -eq 'Subject Alternative Name' }
        $sanList = @()
        
        if ($san) {
            $sanList = $san.Format($true) -split "`n" | ForEach-Object { $_.Trim() } | Where-Object { $_ -ne "" }
        }
        
        # Check if the alias hostname is in the SAN
        $hostInSAN = $sanList | Where-Object { $_ -match [regex]::Escape($HostName) }
        
        $results += [PSCustomObject]@{
            IPAddress = $ip
            Subject = $cert.Subject
            ContainsAlias = ($hostInSAN -ne $null)
            SANList = ($sanList -join ", ")
        }
        
        if ($hostInSAN) {
            Write-Host "  ✓ $ip - Certificate contains '$HostName'" -ForegroundColor Green
        } else {
            Write-Host "  ✗ $ip - Certificate does NOT contain '$HostName'" -ForegroundColor Red
        }
        
        $ssl.Dispose()
        $tcp.Dispose()
        
    } catch {
        Write-Host "  ✗ $ip - Error: $($_.Exception.Message)" -ForegroundColor Red
        $results += [PSCustomObject]@{
            IPAddress = $ip
            Subject = "ERROR"
            ContainsAlias = $false
            SANList = $_.Exception.Message
        }
    }
}

Write-Host "`n========================================" -ForegroundColor Yellow
Write-Host "Summary" -ForegroundColor Yellow
Write-Host "========================================" -ForegroundColor Yellow

$results | Format-Table -AutoSize

$mismatchCount = ($results | Where-Object { -not $_.ContainsAlias }).Count

if ($mismatchCount -gt 0) {
    Write-Host "`n⚠ WARNING: $mismatchCount of $($results.Count) backend server(s) do NOT have '$HostName' in their certificate." -ForegroundColor Red
    Write-Host "This will cause INTERMITTENT errors as DNS round-robin sends you to different backends.`n" -ForegroundColor Red
    Write-Host "Fix options:" -ForegroundColor Yellow
    Write-Host "  1. Ask mail admins to reissue certificates on ALL backends to include '$HostName' in SAN" -ForegroundColor White
    Write-Host "  2. Change Nodinite to use a hostname that exists in ALL backend certificates" -ForegroundColor White
} else {
    Write-Host "`n✓ All backend servers have '$HostName' in their certificates." -ForegroundColor Green
}

Fix Intermittent Errors

You have two options:

Option 1: Ask Mail Admins to Install Certificate on ALL Backends (Recommended)

Request that every SMTP backend server has a certificate containing the published DNS alias (e.g., smtp.example.com) in its SAN list.

Example request to IT Security:

"Our SMTP service uses DNS round-robin with smtp.example.com pointing to multiple backend servers. Currently, only some backends have certificates containing smtp.example.com in the SAN list, causing intermittent TLS handshake failures. Please reissue certificates for ALL SMTP backend servers to include smtp.example.com in the Subject Alternative Name list."

Option 2: Point Nodinite to a Hostname That Exists Everywhere

Identify a hostname that exists in the certificates of ALL backend servers and use that instead.

Example:

# Run the diagnostic script above
.\Test-SMTPBackendCerts.ps1 -HostName smtp.example.com

# Output shows:
#   192.168.1.10 - Contains: mail.example.com, smtp.example.com
#   192.168.1.11 - Contains: mail.example.com              (missing smtp.example.com)
#   192.168.1.12 - Contains: mail.example.com              (missing smtp.example.com)

# Solution: Use mail.example.com (present on ALL backends)

Update Nodinite configuration:

Setting	Old Value (Intermittent)	New Value (Reliable)
Server	`smtp.example.com`	`mail.example.com`

After updating the configuration:

Purge existing queued alarms - See IMPORTANT note above about queue purging
Test with "Execute Alarm test" button to confirm the new hostname works
Monitor the live alarm queue to verify new alarms send successfully

Common Scenarios

Hostname mismatches typically occur in these situations:

Load balancers/DNS aliases - See Intermittent Errors for DNS round-robin scenarios
Internal vs external hostnames - Using smtp.internal.example.com when certificate only contains smtp.example.com
Legacy configurations - Old hostname still configured after certificate migration to new hostname
Wildcard certificate scope - Using multi-level subdomain (e.g., smtp.sub.example.com) with single-level wildcard (*.example.com)

Step 1: Inspect the Server's SSL/TLS Certificate

Before attempting fixes, you must identify which hostnames are actually in the certificate's SAN list.

PowerShell Script: Inspect SMTP Certificate

Save this script as Get-SMTPCertificate.ps1:

<#
.SYNOPSIS
    Retrieves and displays the SSL/TLS certificate from an SMTP server.

.DESCRIPTION
    Connects to an SMTP server on the specified port, performs a TLS handshake,
    and displays the certificate's Subject, Issuer, Thumbprint, and Subject 
    Alternative Name (SAN) list. Optionally exports the certificate to a file.

.PARAMETER HostName
    The SMTP server hostname to connect to (e.g., smtp.example.com).

.PARAMETER Port
    The SMTP port to connect to. Default is 587 (STARTTLS).

.PARAMETER ExportPath
    Optional path to export the certificate file (.cer format).

.EXAMPLE
    .\Get-SMTPCertificate.ps1 -HostName smtp.example.com -Port 587
    
.EXAMPLE
    .\Get-SMTPCertificate.ps1 -HostName mail.example.com -Port 465 -ExportPath ".\mail.example.com.cer"
#>

param(
    [Parameter(Mandatory = $true)]
    [string]$HostName,
    
    [Parameter(Mandatory = $false)]
    [int]$Port = 587,
    
    [Parameter(Mandatory = $false)]
    [string]$ExportPath = ""
)

Write-Host "Connecting to $HostName`:$Port to retrieve SSL/TLS certificate..." -ForegroundColor Cyan

try {
    # Establish TCP connection
    $tcp = New-Object System.Net.Sockets.TcpClient($HostName, $Port)
    
    # Create SSL stream (accept all certificates for inspection)
    $ssl = New-Object System.Net.Security.SslStream(
        $tcp.GetStream(), 
        $false, 
        ({ param($sender, $certificate, $chain, $sslPolicyErrors) return $true })
    )
    
    # Perform TLS handshake
    $ssl.AuthenticateAsClient($HostName)
    
    # Get certificate
    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($ssl.RemoteCertificate)
    
    # Display certificate information
    Write-Host "`n========================================" -ForegroundColor Green
    Write-Host "Certificate Information" -ForegroundColor Green
    Write-Host "========================================" -ForegroundColor Green
    
    Write-Host "`nSubject   : " -NoNewline -ForegroundColor Yellow
    Write-Host $cert.Subject -ForegroundColor White
    
    Write-Host "Issuer    : " -NoNewline -ForegroundColor Yellow
    Write-Host $cert.Issuer -ForegroundColor White
    
    Write-Host "Thumbprint: " -NoNewline -ForegroundColor Yellow
    Write-Host $cert.Thumbprint -ForegroundColor White
    
    Write-Host "Valid From: " -NoNewline -ForegroundColor Yellow
    Write-Host $cert.NotBefore -ForegroundColor White
    
    Write-Host "Valid To  : " -NoNewline -ForegroundColor Yellow
    Write-Host $cert.NotAfter -ForegroundColor White
    
    # Extract and display Subject Alternative Names (SAN)
    Write-Host "`n========================================" -ForegroundColor Cyan
    Write-Host "Subject Alternative Names (SAN)" -ForegroundColor Cyan
    Write-Host "========================================" -ForegroundColor Cyan
    
    $san = $cert.Extensions | Where-Object { $_.Oid.FriendlyName -eq 'Subject Alternative Name' }
    
    if ($san) {
        $sanList = $san.Format($true) -split "`n" | ForEach-Object { $_.Trim() } | Where-Object { $_ -ne "" }
        
        Write-Host "`nThe certificate is valid for the following hostnames:" -ForegroundColor Yellow
        foreach ($name in $sanList) {
            Write-Host "  • $name" -ForegroundColor White
        }
        
        # Check if the hostname you connected to is in the SAN list
        $hostInSAN = $sanList | Where-Object { $_ -match [regex]::Escape($HostName) }
        
        Write-Host "`n========================================" -ForegroundColor Magenta
        Write-Host "Hostname Verification" -ForegroundColor Magenta
        Write-Host "========================================" -ForegroundColor Magenta
        
        Write-Host "`nYou connected to: " -NoNewline -ForegroundColor Yellow
        Write-Host $HostName -ForegroundColor White
        
        if ($hostInSAN) {
            Write-Host "`n✓ MATCH: " -NoNewline -ForegroundColor Green
            Write-Host "The hostname '$HostName' is present in the certificate's SAN list." -ForegroundColor Green
        } else {
            Write-Host "`n✗ MISMATCH: " -NoNewline -ForegroundColor Red
            Write-Host "The hostname '$HostName' is NOT in the certificate's SAN list." -ForegroundColor Red
            Write-Host "`nTo fix this error, configure Nodinite to use one of the hostnames listed above." -ForegroundColor Yellow
        }
    } else {
        Write-Host "`nNo Subject Alternative Names found in certificate." -ForegroundColor Red
        Write-Host "This certificate may only be valid for: $($cert.Subject)" -ForegroundColor Yellow
    }
    
    # Export certificate if path specified
    if ($ExportPath) {
        $bytes = $cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
        [IO.File]::WriteAllBytes($ExportPath, $bytes)
        Write-Host "`n========================================" -ForegroundColor Green
        Write-Host "✓ Saved certificate to: $ExportPath" -ForegroundColor Green
        Write-Host "========================================" -ForegroundColor Green
    }
    
} catch {
    Write-Error "Failed to retrieve certificate: $_"
} finally {
    if ($ssl) { $ssl.Dispose() }
    if ($tcp) { $tcp.Dispose() }
}

Write-Host ""

Run the Script

# Inspect the certificate from your SMTP server
.\Get-SMTPCertificate.ps1 -HostName smtp.example.com -Port 587

# Export certificate to file for further inspection
.\Get-SMTPCertificate.ps1 -HostName smtp.example.com -Port 587 -ExportPath ".\smtp.example.com.cer"

# For SMTPS (implicit TLS on port 465)
.\Get-SMTPCertificate.ps1 -HostName smtp.example.com -Port 465

Example Output

Connecting to smtp.example.com:587 to retrieve SSL/TLS certificate...

========================================
Certificate Information
========================================

Subject   : CN=mail1.example.com
Issuer    : CN=DigiCert TLS RSA SHA256 2020 CA1, O=DigiCert Inc, C=US
Thumbprint: A1B2C3D4E5F6071829384A5B6C7D8E9F0A1B2C3D
Valid From: 1/15/2025 12:00:00 AM
Valid To  : 1/15/2027 11:59:59 PM

========================================
Subject Alternative Names (SAN)
========================================

The certificate is valid for the following hostnames:
  • DNS Name=mail1.example.com
  • DNS Name=mail2.example.com
  • DNS Name=mail.example.com

========================================
Hostname Verification
========================================

You connected to: smtp.example.com

✗ MISMATCH: The hostname 'smtp.example.com' is NOT in the certificate's SAN list.

To fix this error, configure Nodinite to use one of the hostnames listed above.

Tip
The script output clearly shows which hostnames are valid for the certificate. You must use one of these hostnames in your Nodinite Email Alarm Plugin configuration.

Step 2: Identify the Correct Hostname

Based on the certificate inspection output, identify a hostname from the SAN list that you can use.

Option A: Use a Hostname from the SAN List

If the certificate contains hostnames like mail.example.com, mail1.example.com, or mail2.example.com, update your Nodinite Email Alarm Plugin configuration to use one of these instead.

Example:

Before (Mismatch): smtp.example.com (not in SAN)
After (Match): mail.example.com (present in SAN)

Option B: Use a Wildcard-Matched Hostname

If the certificate contains a wildcard entry like *.example.com, you can use any single-level subdomain:

✅ Valid: smtp.example.com (matches *.example.com)
✅ Valid: mail.example.com (matches *.example.com)
❌ Invalid: smtp.internal.example.com (two levels - does NOT match *.example.com)

Warning
Wildcard certificates only match one level of subdomain. See Wildcard troubleshooting if you have a multi-level hostname.

Step 3: Update Nodinite Email Alarm Plugin Configuration

Update the SMTP Server Hostname

Navigate to Administration → Settings → Alarm Plugins → E-mail with options
Update the Server field to use a hostname from the certificate's SAN list
Click Save
Purge existing queued alarms (if any) - See queue purge note in Intermittent Errors section
Test email delivery using the Execute Alarm test button

Example Configuration:

Setting	Old Value (Mismatch)	New Value (Match)
Server	`smtp.example.com`	`mail.example.com`
Port	`587`	`587`
Use SSL/TLS	✅ Checked	✅ Checked
Username	`user@example.com`	`user@example.com`
Password	`********`	`********`

Verify Configuration

# Test DNS resolution for the new hostname
Resolve-DnsName mail.example.com

# Test SMTP connectivity
Test-NetConnection -ComputerName mail.example.com -Port 587

What If No Valid Hostname Exists in the Certificate?

If the certificate's SAN list contains no hostnames that are accessible to you (e.g., only contains internal hostnames like mail-internal.corp.local but you need external access), you have two options:

Option A: Request Certificate Reissuance (Recommended)

Work with your IT Security or Infrastructure team to reissue the certificate to include the hostname you need.

Example request:

"Please reissue the SSL/TLS certificate for our SMTP server to include smtp.example.com in the Subject Alternative Name (SAN) list. The current certificate only contains mail1.example.com and mail2.example.com, but our monitoring system connects via smtp.example.com."

Option B: Connect Directly to a Backend Server

If the SMTP service uses multiple servers behind a load balancer, you can configure Nodinite to connect directly to one of the backend servers whose hostname IS in the certificate.

Example:

Load Balancer hostname: smtp.example.com (not in SAN)
Backend servers: mail1.example.com, mail2.example.com (both in SAN)
Solution: Update Nodinite to use mail1.example.com

Warning
Bypassing load balancers may reduce redundancy and failover capabilities. Discuss with your infrastructure team.

After obtaining a valid hostname, return to Step 3 to update Nodinite.

Troubleshooting Common Issues

Note
If you cannot connect to the SMTP server at all (before certificate validation), see FAQ - DNS Resolution Errors for DNS lookup and network connectivity troubleshooting.

Issue: "Certificate is valid, but hostname still mismatches"

Cause: You may be connecting to the wrong server in a load-balanced environment.

Solution: Trace the Actual Server

# Identify which server you are actually connecting to
$hostname = "smtp.example.com"
$ip = (Resolve-DnsName $hostname).IPAddress

Write-Host "Resolves to: $ip"

# Get certificate from that specific IP
.\Get-SMTPCertificate.ps1 -HostName $ip -Port 587

Issue: "SAN list contains wildcard, but still fails"

Cause: Wildcard certificates only match one subdomain level.

Solution: Verify Subdomain Depth and Request Proper Certificate

✅ *.example.com matches smtp.example.com (one level)
❌ *.example.com does NOT match smtp.internal.example.com (two levels)

For multi-level subdomains, request a certificate with:

The full hostname in the SAN (e.g., smtp.internal.example.com), OR
A wildcard at the appropriate level (e.g., *.internal.example.com)

Issue: "Certificate contains the hostname, but IP address is used"

Cause: You configured Nodinite with an IP address instead of a hostname.

Solution: Use Hostname Instead of IP

Even if the certificate contains smtp.example.com, connecting via IP address (e.g., 192.168.1.10) will fail hostname verification.

❌ Server: 192.168.1.10          (IP address - fails)
✅ Server: smtp.example.com      (Hostname - succeeds)

Issue: "Multiple certificates in the chain, which one matters?"

Cause: Only the leaf certificate (the server's certificate) is checked for hostname matching.

Solution: Inspect the Leaf Certificate Only

The PowerShell script provided retrieves the leaf certificate automatically. Intermediate and root certificates in the chain are not checked for hostname matching.

Security Implications

Caution
Hostname verification is a critical security feature that prevents:

Man-in-the-middle attacks - Attackers cannot present a valid certificate for a different domain

Phishing - Ensures you are connecting to the intended server

Certificate misuse - Prevents valid certificates from being used on unintended servers

Nodinite does not provide an option to disable hostname verification. The certificate must match the hostname you configure.

Summary Checklist

Before contacting support, verify:

✅ Ran Get-SMTPCertificate.ps1 to inspect the server's certificate SAN list
✅ For intermittent errors: Ran Test-SMTPBackendCerts.ps1 to check all backend servers behind DNS alias
✅ Identified at least one hostname from the SAN list that is accessible on all backend servers
✅ Updated Nodinite Email Alarm Plugin Server field to use SAN-listed hostname
✅ Purged existing queued alarms with old settings (Administration → Monitor Management → Alarm Queue)
✅ Verified DNS resolution for the new hostname
✅ Tested SMTP connectivity with Test-NetConnection
✅ Confirmed the hostname is not an IP address
✅ If using wildcard certificates, verified subdomain depth matches wildcard scope
✅ Tested email delivery with Execute Alarm test button in Nodinite
✅ For intermittent errors: Monitored live alarm queue to confirm errors no longer occur

Next Steps

Related FAQs:

Alarm Plugin Configuration:

Support:

Support

Explore Nodinite for 30 days – completely free

See how Nodinite resolves your technical issues, in a

LIVE Demo!

SSL/TLS Certificate Name Mismatch Errors

Problem

Root Cause

Intermittent Errors (Test Succeeds, Live Alarms Fail)

Root Cause: DNS Round-Robin with Inconsistent Backend Certificates

How to Diagnose Intermittent Errors

Fix Intermittent Errors

Option 1: Ask Mail Admins to Install Certificate on ALL Backends (Recommended)

Option 2: Point Nodinite to a Hostname That Exists Everywhere

Common Scenarios

Step 1: Inspect the Server's SSL/TLS Certificate

PowerShell Script: Inspect SMTP Certificate

Run the Script

Example Output

Step 2: Identify the Correct Hostname

Option A: Use a Hostname from the SAN List

Option B: Use a Wildcard-Matched Hostname

Step 3: Update Nodinite Email Alarm Plugin Configuration

Update the SMTP Server Hostname

Verify Configuration

What If No Valid Hostname Exists in the Certificate?

Option A: Request Certificate Reissuance (Recommended)

Option B: Connect Directly to a Backend Server

Troubleshooting Common Issues

Issue: "Certificate is valid, but hostname still mismatches"

Solution: Trace the Actual Server

Issue: "SAN list contains wildcard, but still fails"

Solution: Verify Subdomain Depth and Request Proper Certificate

Issue: "Certificate contains the hostname, but IP address is used"

Solution: Use Hostname Instead of IP

Issue: "Multiple certificates in the chain, which one matters?"

Solution: Inspect the Leaf Certificate Only

Security Implications

Summary Checklist

Next Steps

Related Topics

...