Configuring and using LDAP - "error: x509: certificate signed by unknown authority"

[eduardolucioac]

Hi everyone! It's me again!

We are trying to configure OpenShift (OKD) to consume our LDAP for the authentication process.

Our LDAP directory does not require authentication ("bindPassword", "secret"). It is also not an LDAPS and therefore does not need a certificate ("configmap").

In view of the above, we are configuring access via LDAP as shown below...

cat <<EOF | oc apply -f -
---
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: ldapidp
    mappingMethod: claim
    type: LDAP
    ldap:
      attributes:
        id:
        - dn
        email:
        - mail
        name:
        - cn
        preferredUsername:
        - uid
      bindDN: ""
      insecure: true
      url: "ldap://10.2.0.5:389/dc=somedm,dc=abc,dc=xy?uid"
EOF

However, when we try to use a valid user the following error happens...

[root@okd-services ~]# oc login -u someuser
error: x509: certificate signed by unknown authority

What could be going wrong?

We are following these guidelines: https://docs.okd.io/latest/authentication/identity_providers/configuring-ldap-identity-provider.html

[]'s

[pflaeging]

Hi, I think you’ve got a new installation. The warning about the certificate is not related to the ldaps connect, this warning comes from the API access to your server. Default there’s a self signed certificate on the API. You can check back with: curl -vv -k https://api.myokdserver.whateverdomain:6443/ <https://api.myokdserver.whateverdomain:6443/> Now you can see the cert! You can exchange these cert, but’s that’s another task ;-) peter pfläging ***@***.*** ***@***.***> 📞+43 699 1410 7990 (Tel, Signal, Telegram) 🏠 In den Jochen 49, A-2122 Ulrichskirchen, Austria 🌍 https://www.pflaeging.net/ <http://www.pflaeging.net/> 🌍 https://www.stickiebox.org/ <http://www.pflaeging.net/>

…

Am 29.07.2021 um 02:06 schrieb Eduardo Lúcio Amorim Costa ***@***.***>: Hi everyone! It's me again! We are trying to configure OpenShift (OKD) to consume our LDAP for the authentication process. Our LDAP directory does not require authentication ("bindPassword", "secret"). It is also not an LDAPS and therefore does not need a certificate ("configmap"). In view of the above, we are configuring access via LDAP as shown below... cat <<EOF | oc apply -f - --- apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: ldapidp mappingMethod: claim type: LDAP ldap: attributes: id: - dn email: - mail name: - cn preferredUsername: - uid bindDN: "" insecure: true url: "ldap://10.2.0.5:389/dc=somedm,dc=abc,dc=xy?uid" EOF However, when we try to use a valid user the following error happens... ***@***.*** ~]# oc login -u someuser error: x509: certificate signed by unknown authority What could be going wrong? We are following these guidelines: https://docs.okd.io/latest/authentication/identity_providers/configuring-ldap-identity-provider.html <https://docs.okd.io/latest/authentication/identity_providers/configuring-ldap-identity-provider.html> []'s — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#797>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF4R6AUW3MWNIDF7XZNRK3T2CLQ5ANCNFSM5BFLP2RA>.

[eduardolucioac]

As you said, we were able to obtain information about the certificate...

[root@okd-services ~]# curl -vv -k https://api.mbr.mydomain.net:6443/
*   Trying 10.3.0.3...
* TCP_NODELAY set
* Connected to api.mbr.mydomain.net (10.3.0.3) port 6443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=api.mbr.mydomain.net
*  start date: Jul 28 01:16:16 2021 GMT
*  expire date: Aug 27 01:16:17 2021 GMT
*  issuer: OU=openshift; CN=kube-apiserver-lb-signer
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* Using Stream ID: 1 (easy handle 0x55a9619123f0)
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET / HTTP/2
> Host: api.mbr.mydomain.net:6443
> User-Agent: curl/7.61.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* Connection state changed (MAX_CONCURRENT_STREAMS == 2000)!
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
< HTTP/2 403 
< audit-id: ca8aeab6-3d76-4d75-8377-ab41c7c630d5
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< x-kubernetes-pf-flowschema-uid: a1513885-71e5-4f4e-a552-9168f4512cc2
< x-kubernetes-pf-prioritylevel-uid: a53ef89b-0e00-4cf9-93bd-bb98d9d35abb
< content-length: 233
< date: Thu, 29 Jul 2021 15:36:51 GMT
< 
* TLSv1.3 (IN), TLS app data, [no content] (0):
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
* Connection #0 to host api.mbr.mydomain.net left intact

But, what should we do with this information to address the problem...

error: x509: certificate signed by unknown authority

Could you provide us with more information?

Thanks! =D

[]'s

[christianh814]

This might be a client side issue. Try oc login --insecure-skip-tls-verify

[eduardolucioac]

Solution here!

https://github.com/eduardolucioac/okd_bare_metal#avoid-error-x509-certificate-signed-by-unknown-authority-okd_services

[]'s