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

1,612 views
Skip to first unread message

Eduardo Lúcio Amorim Costa

unread,
Jul 28, 2021, 7:58:54 PM7/28/21
to okd-wg
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 -
---
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
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?


[]'s

Zryty ADHD

unread,
Jul 29, 2021, 3:34:54 AM7/29/21
to Eduardo Lúcio Amorim Costa, okd-wg
This is look similiar to error which i have using harbor for image repo.
I resolve this exporting certificate from it  (harbor) and put him in /etc/docker/certs.d 
I cretcreate the folder named like my service for example harbor.example.com or IP which you use. Then restart docker service. This resolve problem.

--
You received this message because you are subscribed to the Google Groups "okd-wg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okd-wg+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okd-wg/8a882ca6-2fcb-4da7-ac98-da480faa7590n%40googlegroups.com.

Eduardo Lúcio Amorim Costa

unread,
Jul 29, 2021, 11:21:19 AM7/29/21
to okd-wg
Zryty,

Thanks for your response. But I really couldn't understand what solution you adopted. Could you provide more information?

[],s

Eduardo Lúcio Amorim Costa

unread,
Jul 29, 2021, 11:27:25 AM7/29/21
to okd-wg
Hello all!

A minha análise de momento é que o que está ocorendo é um bug ou a documentação do OKD e da RH estão desatualizadas já que colocam como opcionais o password e o certificado...
My analysis at the moment is that what's happening is a bug or the OKD and HR documentation are out of date as they put the password and certificate as optional...

"
Optional DN to use to bind during the search phase. Must be set if bindPassword is defined.
Optional reference to an OpenShift Container Platform Secret object containing the bind password. Must be set if bindDN is defined.
Optional: Reference to an OpenShift Container Platform ConfigMap object containing the PEM-encoded certificate authority bundle to use in validating server certificates for the configured URL. Only used when insecure is false.
"

Can anyone confirm this?

Zryty ADHD

unread,
Jul 29, 2021, 11:41:01 AM7/29/21
to Eduardo Lúcio Amorim Costa, okd-wg
My solution is simple.
On Harbor example. I install Harbor and go to login page with my browser to export certificate and save to file. 

After ceet extract I edit file with notepad and copy.
When I have this. The way is very easy. You need to log to your master server and go to /etc/docker/certs.d and there make the catalog with his name. My was harbor.example.com and go info it and make file name ca.crt and past copied early certificate text. Save file and restart docker service. 
Here is instruction how to extract certificate from Windows Ldap


To view this discussion on the web visit https://groups.google.com/d/msgid/okd-wg/9e7a1b3c-dec1-471c-9981-57016c6038ddn%40googlegroups.com.

Eduardo Lúcio Amorim Costa

unread,
Jul 29, 2021, 12:09:31 PM7/29/21
to okd-wg

"
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:


Now you can see the cert!

You can exchange these cert, but’s that’s another task ;-)


peter pfläging

Eduardo Lúcio Amorim Costa

unread,
Jul 29, 2021, 12:10:38 PM7/29/21
to okd-wg
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
> 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
Reply all
Reply to author
Forward
0 new messages