The Credential Type switch

With Auth Mode set to Azure Client Credentials (on both MCP connection and HTTP connection dialogs), a Credential Type control chooses how the connection authenticates:

  • πŸ”‘ Client Secret β€” today’s behaviour: an inline secret or an Azure Key Vault reference.
  • πŸ“œ Certificate β€” a certificate from the local store, used with ClientCertificateCredential.
New Connection dialog with the Credential Type switch set to Certificate and the inline certificate generator expanded

Switching Credential Type to Certificate reveals the certificate panel β€” pick an existing certificate or create one inline.

Only one credential kind is persisted: saving in certificate mode clears any secret/Key Vault reference, and vice versa.

Creating a certificate inline

Choose οΌ‹ Create new certificate… in the certificate dropdown to expand the inline generator:

FieldNotes
NameStore name β€” lowercase letters, digits, hyphens (e.g. finance-api-cert). Pre-filled from the connection name.
Subject (CN)Defaults to mcp-explorer-{name}.
Key sizeRSA 2048 (default) or 4096.
Valid for6, 12 (default), or 24 months.
PFX passwordOptional β€” also writes a password-protected cert.pfx alongside the PEM files.

Generate certificate runs with step-by-step progress: key-pair generation, X.509 creation (SHA-256), file writes, and metadata/audit. Generation is pure .NET β€” no OpenSSL required.

Certificate summary card showing thumbprint and expiry with the Upload to App Registration button

After generation: the summary card shows the thumbprint and expiry, with upload one click away.

You can also create certificates from the Certificates page (New Certificate), and pick them later from any connection dialog.

Uploading to an App Registration

Upload to App Registration adds the public certificate to the app’s key credentials via Microsoft Graph β€” the private key never leaves the machine. The button enables once a Client ID is selected above (use Browse App Registrations… to pick one). Steps:

  1. Load the certificate from the local store
  2. Fetch the app registration (requires az login or equivalent DefaultAzureCredential chain)
  3. Append an AsymmetricX509Cert key credential β€” idempotent: re-uploading the same thumbprint is a no-op
  4. Re-read and verify the thumbprint landed

Your account needs Application.ReadWrite.OwnedBy (or Owner on the app registration); a permission failure shows a clear, retryable error and the certificate stays safe in the local store β€” you can always upload later from the Certificates page.

Entra ID propagation β€” Graph reads can lag a successful upload by a few seconds. The verify step polls with backoff; if the credential still isn’t visible it reports the upload as succeeded-pending-verification and the Verify action on the Certificates page confirms (and reconciles) it shortly after.

Testing token acquisition

After uploading, Test token acquisition runs a dry-run ClientCertificateCredential flow against your Tenant ID / Client ID / Scope and reports the token expiry on success. Newly uploaded certificates can take 30–60 seconds to propagate in Entra ID β€” if the test fails immediately after an upload, wait a moment and retry.

The Certificates page

Infrastructure β†’ Certificates lists everything in the local store:

  • Stat tiles β€” total certificates, uploaded to app registrations, expiring within 30 days, expired.
  • Table β€” subject, SHA-1 thumbprint chip (click to copy), expiry status tag, App Registration upload state, and how many connections reference each certificate.
  • Detail row (expand) β€” files on disk, full SHA-1/SHA-256 thumbprints, used-by chips, per-app Verify / Manage actions, and export buttons.

Downloads: PEM returns the public certificate only. Export PFX (includes the private key) always requires a password and is audit-logged. Deleting a certificate is blocked with a clear message while any connection or HTTP API definition still references it.