Fresh install fails to connect: "x509: certificate signed by unknown authority" against local MATLAB connector

[procect-ojm]

Description

Environment

• OS: Windows 11 Home (Build 26200)
• MATLAB: R2025b (25.2.0.2998904), Home License
• MATLAB MCP Server: v0.11.1 (freshly reinstalled from matlab-mcp-server.mcpb)
• Client: Claude Desktop

Summary

After a completely fresh reinstall of the MCP server extension (uninstall old
"MATLAB MCP Core Server", full Claude Desktop restart, install new
"MATLAB MCP Server" v0.11.1), every tool call still fails with
"MATLAB session is not alive". Server logs show the underlying cause is a
TLS certificate trust failure when the Go server tries to reach the MATLAB
connector on localhost:

error: failed to send request: Post "https://localhost:31516/messageservice/json/state":
tls: failed to verify certificate: x509: certificate signed by unknown authority

This repeats continuously until the discovery timeout, then the watchdog
kills the MATLAB process and retries, indefinitely, with the same error.

Steps to reproduce

1. Install matlab-mcp-server.mcpb in Claude Desktop (fresh install)
2. Set Initial Working Folder and Log Folder in extension settings
3. Restart Claude Desktop
4. Call any tool (e.g. detect_matlab_toolboxes) from Claude

Observed

• MATLAB itself launches fine from command line (matlab -batch "disp('hello')" works)
• The MATLAB connector does start and does write out a
  connector.securePort file in the session directory
• The MCP server's own TLS client rejects the connector's self-signed
  certificate as "signed by unknown authority"
• Disabling all Norton 360 protection (Auto-Protect, Firewall, etc.) for
  15 minutes did NOT change this result — same error persists
• This started after a system memory upgrade (8GB→32GB) and, separately,
  after renaming/regenerating %APPDATA%\MathWorks\MATLAB to troubleshoot
  an unrelated browser-side certificate warning
  (ERR_CERT_AUTHORITY_INVALID when opening MATLAB's own web UI feature)

Expected

The MCP server should be able to trust the MATLAB connector's own
self-signed certificate for localhost communication, or provide a
documented way to configure/regenerate this trust relationship.

Logs available

Full JSON server/watchdog logs available on request (large — contain
repeated identical TLS errors during the discovery retry loop).

[procect-ojm]

Additional finding: the certificate itself is self-signed with generic placeholder subject

I inspected the cert.pem written to the MATLAB session directory
(logs/matlab-session-*/cert.pem) using openssl x509 -text -noout.
This confirms the certificate is self-signed (Issuer == Subject), with a
generic/template subject that doesn't appear to be tied to any real CA or
to my machine specifically:

Issuer:  C=US, O=company, CN=127.0.0.1, OU=engineering
Subject: C=US, O=company, CN=127.0.0.1, OU=engineering
Validity: 1 year from generation time
SAN: IP Address:127.0.0.1, DNS:localhost, DNS:127.0.0.1

So the certificate itself looks like a standard, expected MATLAB connector
self-signed cert (generated fresh per session) — nothing corrupted or
unusual about it on its own.

This suggests the MCP server is meant to explicitly trust/pin this exact
cert.pem file when connecting to the connector (rather than relying on
standard system CA validation, which of course rejects any self-signed
cert). Whatever mechanism is supposed to read cert.pem from the session
directory and add it to the Go client's trusted cert pool for that
connection does not appear to be working in my environment — the client
falls back to standard verification and rejects it as
"signed by unknown authority".

Happy to test a debug build or provide the full cert.pem/cert.key pair
from a fresh session if that helps narrow down where the trust step is
failing.

[ybenouag]

Hello @procect-ojm, thanks for reaching out.

On the step to reproduce the issue, no step actually runs the shareMATLABSession. This will regenerate the certificate and hopefully fix this issue.

However, if you have already done this, it would be very helpful if you could share your MATLAB MCP Server config (flags used and their values) + any logs from Claude Desktop so we can trace back what and when things went wrong.

Thanks a lot.
Yannis.

[procect-ojm]

Thanks Yannis, I tried this.

What I did

1. Installed MATLABMCPServerToolbox.mltbx (this was not previously
   installed — shareMATLABSession was undefined before this).
2. Confirmed it installed correctly:

   >> which shareMATLABSession
   C:\Users\heroh\AppData\Roaming\MathWorks\MATLAB Add-Ons\Toolboxes\MATLAB MCP Server Toolbox\shareMATLABSession.m
   

3. Ran shareMATLABSession in the MATLAB Command Window (no error, no
   output).
4. Retried the tool call from Claude Desktop.

Result

Same error persists:

error: failed to send request: Post "https://localhost:31516/messageservice/json/state":
tls: failed to verify certificate: x509: certificate signed by unknown authority

One additional detail from this attempt: the server also tried port 31520
(presumably the port shareMATLABSession opened) and got a different
error there — connection actively refused, not a TLS error:

error: failed to send request: Post "https://localhost:31520/messageservice/json/state":
dial tcp [::1]:31520: connectex: No connection could be made because the target machine actively refused it.

So it seems the MCP server never successfully reaches the
shareMATLABSession-opened port at all (connection refused), and falls
back to spawning its own new MATLAB session (auto session mode), which
then hits the same self-signed cert rejection as before on a new port
(31517/31518 in different runs).

Config

"LogLevel":"info"
"DisableTelemetry":false
"PreferredLocalMATLABRoot":""
"PreferredMATLABStartingDirectory":"C:\\Users\\heroh\\ClaudeProjects\\My3rdProject"
"UseSingleMATLABSession":true
"InitializeMATLABOnStartup":false
"MATLABDisplayMode":"desktop"
"MATLABSessionMode":"auto"
"MATLABSessionConnectionTimeout":5000000000
"MATLABSessionDiscoveryTimeout":30000000000

MATLAB R2025b (25.2.0.2998904), Windows 11 Home, MATLAB MCP Server v0.11.1.

Happy to share the full logs (server + watchdog + session dirs) directly if
that would help — they're fairly large due to the repeated retry loop, so I
held off pasting them in full here.

[agoldsbo]

Thanks for the additional info. I think it would be helpful to see the logs at this point. The best way we can do that is to contact technical support. They will create a case for you which will be sent to me. You will have the opportunity to upload the logs in a secure way that doesn't risk publishing any of your personal details to the internet. Would that be ok?

[procect-ojm]

Yes, that works for me — I'll contact support and reference this issue.

One more data point in the meantime: I reproduced the exact same error
on a completely fresh MATLAB R2026a install on a separate drive (D:),
and also with Norton AntiTrack fully uninstalled. Same TLS error in both
cases, so this doesn't appear to be environment- or antivirus-specific.

[ybenouag]

Hello @procect-ojm I had another review of this issue,

Thanks, that extra data point is genuinely useful. Reproducing on a fresh R2026a install on a separate drive, with Norton AntiTrack fully removed, effectively rules out antivirus and machine-specific state, which matches what we would expect from the code path.

Some context on why this error is interesting. When the server starts its own MATLAB, its HTTP client trusts only the per-session cert.pem written into the session directory. It is pinned as the sole trusted CA, with no fallback to the system trust store. So "x509: certificate signed by unknown authority" does not mean a generic self-signed cert is being rejected. It means the certificate actually presented on the connector port does not match the cert.pem we pinned for that session. Those two just need to be the same cert.

There is a quick check that confirms this directly. First, in a standalone MATLAB (one you started yourself, not launched by the MCP server), run:

connector.ensureServiceOn
connector.securePort
connector.getCertificateLocation

securePort prints the port number (for example 31516), and getCertificateLocation prints the full path to the cert.pem the connector is using (for example C:\Users\<you>\AppData\Local\Temp\...\matlab-session-...\cert.pem). I verified both commands on R2026a; getCertificateLocation returns the session cert path as expected.

Then, in a terminal, paste those two values into the commands below. Replace PORT with the number from securePort, and CERT_PATH with the path from getCertificateLocation:

openssl s_client -connect localhost:PORT -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256
openssl x509 -in "CERT_PATH" -noout -fingerprint -sha256

The first line prints the fingerprint of the certificate served on the wire; the second prints the fingerprint of the cert.pem on disk.

• If the two fingerprints match, the connector is serving the same cert we pin, and we should chase something intercepting the localhost TLS connection instead. On a healthy setup they match.
• If they differ, it confirms the connector is serving a different certificate than the one written to the session cert.pem, which is exactly what produces this error. Given your note that this began after regenerating %APPDATA%\MathWorks\MATLAB (where the connector keeps its certificate state), a stale or cached cert there is the prime suspect.

Fingerprints and the cert path contain no sensitive data, so those outputs are safe to paste here or into the support case alongside the full logs.

[procect-ojm]

Thanks Yannis — I ran the fingerprint check you suggested (using PowerShell's X509Certificate2 instead of openssl, which isn't installed on this machine).

Setup
Confirmed MATLAB Installation Path was correctly set to C:\Program Files\MATLAB\R2025b (not the R2026a I'd been testing with previously) and restarted Claude Desktop.
Triggered a tool call so the MCP server spawned its own MATLAB session.
Caught the session while it was still alive (before the 10-minute auto-close), matlab-root C:\Program Files\MATLAB\R2025b, session port 31518, pid 15788.
Fingerprint comparison

Cert pinned by the MCP server (cert.pem in the session directory):

50FF187B958381573FAD0096CD87F3D757A1FDA2F6046F93A3B039B27181EFC1

Cert actually served on localhost:31518 (captured via a PowerShell SslStream handshake):

50FF187B958381573FAD0096CD87F3D757A1FDA2F6046F93A3B039B27181EFC1

They match. So per your diagnosis, this rules out a stale/mismatched cert — the connector is serving exactly the cert that was pinned for it.

This points to something intercepting or interfering with the MCP server's own TLS handshake to localhost specifically, since a plain PowerShell/.NET TLS client completes the same handshake against the same port without any error.

For reference, I also separately verified a manually-started MATLAB instance (not spawned by MCP, using the persistent thisMatlab.pem, port 31516) — that fingerprint also matched between file and wire. So in both the "existing session" and "MCP-spawned session" cases, the cert itself is never the problem; only the Go MCP server's client fails to validate it.

I've also opened MathWorks support Case #08878292 for this issue and will share full logs there.