CmfRestClass reconciliation fails with HTTP 400 when configuring TLS for CMF

Stream Processing
1

Hi everyone,

I am encountering and HTTP 400 error during the reconciliation of CmfRestClass, CustomResource of Confluent For Kubernetes (CFK) to manage Flink resources and communicate with the REST API of Confluent Manager for Apache Flink® (CMF).

Environment Details
CFK Version: 3.3.1
CMF Version: 2.4.2

Scenario & Configuration
We are securing communication between CFK and CMF using TLS with P-256 (ECDSA / prime256v1) certificates that contains the CMF service internal FQDN as Subject Alternative Name (cmf-service.confluent-platform.svc.cluster.local).

Here is the CmfRestClass manifest structure being applied:

apiVersion: platform.confluent.io/v1beta1
kind: CMFRestClass
metadata:
  name: default
spec:
  cmfRest:
    endpoint: http://cmf-service.confluent-platform.svc.cluster.local:80
    ## TLS configuration
    tls:
      secretRef: cmfrestclass-cert

The Secret cmfrestclass-cert contains the TLS Group 1: PEM-encoded files holding cacerts.pem, the CA certificate for CMF’s P-256 TLS endpoint.

Symptom & Error

{
   "level":"ERROR",
   "time":"2026-10-05T09:40:59.245Z",
   "name":"cmfrestclass","caller":"log/log.go:53",
   "msg":"apply failed","name":"default","namespace":"confluent-platform",
   "error":"400"
}

What We Have Verified

  1. Truststore Validity: the CMF and CmfRestClass CA certificates are identicals.
  2. Direct Connectivity: Reaching CMF via HTTPS directly using curl with the CA certificate works as expected (200 OK)
curl -v --cacert cacerts.pem https://localhost:30080/cmf/api/v1/environments

* Host localhost:30080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:30080...
* connect to ::1 port 30080 from ::1 port 34444 failed: Connection refused
*   Trying 127.0.0.1:30080...
* Connected to localhost (127.0.0.1) port 30080
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: cacerts.pem
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=flink.internal
*  start date: Oct  2 08:08:45 2026 GMT
*  expire date: Dec 31 08:08:45 2026 GMT
*  subjectAltName: host "localhost" matched cert's "localhost"
*  issuer: CN=flink.internal
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/1.x
> GET /cmf/api/v1/environments HTTP/1.1
> Host: localhost:30080
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200

Questions

  1. Is there a known limitation or specific requirement in CFK/CMF when handling P-256 (ECDSA) elliptic curve certificates in CmfRestClass ?
  2. Is there a specific schema requirement for the Secret referenced in spec.cmfRest.tls.secretRef ?
  3. Has anyone encountered a 400 error during CmfRestClass reconciliation and how have you fixed it ?

Any insights or debugging pointers would be greatly appreciated!

Thanks!

2

Hey,
looks like the endpoint you’ve configured is `endpoint: http://cmf-service.confluent-platform.svc.cluster.local:80`. If the protocol is `http`, CFK does not use the provided TLS config.

3

OMG !!! I feel so embarrassed! :face_with_peeking_eye:
@rmetzger you were completely right ! Changing the endpoint to https fixed it immediately.
Sorry for the silly mistake and thank you @rmetzger for your time to help!

4

No problem at all. Based on this issue, I will look into improving the error message that CFK is returning in this case to be a bit more specific. It is also the product’s partial fault that you ran into this situation.