Skip to content

Aembit Cloud and Aembit Edge stop trusting compromised eMudhra certificates

In October 2026, a compromise exposed the private keys of eight emSign intermediate certificate authorities operated by eMudhra. Anyone holding those keys can issue certificates that chain to a widely trusted root certificate. Aembit Cloud and the Aembit releases in this entry reject certificates from these certificate authorities.

Aembit Cloud

Aembit Cloud no longer trusts the emSign ECC Root CA - G3 and AAA Certificate Services root certificates, so it rejects certificates from the compromised certificate authorities. Aembit applied this change to Aembit Cloud for you.

Aembit Edge

Upgrade each of the following that you run to the listed version or later:

  • Agent Proxy 1.35.6254, for the container image and the virtual machine installers. Agent Proxy rejects certificates from the compromised certificate authorities whatever the host trust store contains.
  • Aembit CLI 1.35.6254, which rejects them the same way.
  • Agent Controller 1.35.3776, for the Linux container image. On a virtual machine, Agent Controller uses the host operating system’s trust store, so it rejects these certificates only after the host stops trusting both root certificates.
  • Agent Injector 1.35.446
  • AWS Lambda Extension and AWS Lambda Layer 1.35.199, which include Agent Proxy 1.35.6254.
  • MCP Identity Gateway 1.35.6263
  • Aembit Secrets Operator 1.35.394
  • Helm Chart 1.35.575, which deploys Agent Proxy 1.35.6254, Agent Controller 1.35.3776, and Agent Injector 1.35.446 by default.
  • AWS ECS Terraform 1.35.5, which deploys Agent Proxy 1.35.6254 and Agent Controller 1.35.3776 by default.

Aembit Terraform Provider

Aembit Terraform Provider 1.35.1 and later reject certificates from the compromised certificate authorities.

Aembit Secrets Operator dependency security updates

Aembit Secrets Operator 1.34.358 updates its Go toolchain and bundled Go libraries to fix published vulnerabilities that container image scanning reported in the earlier versions. The update requires no configuration change. Upgrade to 1.34.358 or later to pick up the fixes.

These updates shipped in the same build as Aembit Secrets Operator now delivers X.509-SVID certificates. For the latest available versions, see the Edge Components Supported Versions page.

Aembit Secrets Operator now delivers X.509-SVID certificates

Aembit Secrets Operator 1.34.358 and Aembit Secrets Operator Helm chart 1.34.358 are now available.

Secrets Operator now delivers X.509-SVID certificates to your Kubernetes workloads. When an AembitSecretRefreshSchedule sets credentialType: X509Svid, Secrets Operator generates a private key inside the cluster and obtains a signed certificate from Aembit. It writes both to a kubernetes.io/tls Secret that your workload uses for mutual TLS. See Deliver X.509-SVID certificates with Secrets Operator.

  • New X509Svid credential type: The Secret holds tls.crt with the signed certificate chain and tls.key with the private key. Secrets Operator sends Aembit only a certificate signing request, so the private key never leaves the cluster.
  • Automatic renewal: Secrets Operator refreshes the certificate before it expires.
  • TLS Secret type: X509Svid writes a kubernetes.io/tls Secret, while every other credential type writes a generic Secret, so switching a schedule to or from X509Svid deletes and recreates the target Secret. See Credential types and Secret data keys.

Aembit Secrets Operator now supports more credential types

Aembit Secrets Operator 1.32.322 is now available.

Secrets Operator now retrieves any credential type your Access Policy issues—not just HashiCorp Vault tokens. A new credentialType field on the AembitSecretRefreshSchedule resource selects which Credential Provider type Aembit uses, and the managed Kubernetes Secret mirrors the Aembit Edge API credentials response for that provider.

  • New credentialType field: Choose OAuthToken (the default), ApiKey, UsernamePassword, AwsStsFederation, or GoogleWorkloadIdentityFederation. Each type writes its own Secret data keys—for example, UsernamePassword produces username and password, and AwsStsFederation produces awsAccessKeyId, awsSecretAccessKey, and awsSessionToken. See Credential types and Secret data keys.
  • Backward compatible: Schedules that omit credentialType keep writing a single token key, so existing HashiCorp Vault and cert-manager configurations need no change.
  • Clearer mismatch errors: When credentialType doesn’t match the configured Credential Provider, the schedule reports Aembit Edge API returned a credentials response with no populated fields instead of writing a blank Secret.
  • AWS credential redaction: Secrets Operator redacts the AWS access key, secret access key, and session token values from its debug logs.

Aembit Secrets Operator now available

Aembit Secrets Operator 1.31.298 is now available.

Secrets Operator is a Kubernetes operator that authenticates to the Aembit platform and synchronizes credentials into Kubernetes Secrets. Applications consume managed secrets the same way they consume any other Kubernetes Secret.

Key capabilities in this release:

  • Kubernetes Service Account authentication: Authenticate using the operator’s in-cluster ServiceAccount token, validated against the cluster’s OIDC endpoint. No per-cluster signing key required. Verified on Amazon EKS and K3s. See Set up Secrets Operator for configuration.
  • OIDC symmetric key authentication: Alternatively, authenticate using OIDC tokens with symmetric key signing (HS256) for custom claims and non-Kubernetes identity scenarios.
  • Proactive credential renewal: Credentials refresh at 80% of their TTL, or sooner when you configure a shorter refreshInterval, ensuring applications always have a valid credential.
  • Multi-namespace install: You can now use the same Helm release name across multiple namespaces on the same cluster without resource name conflicts.