# LDAP Result Code 200 "Network Error": tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead

**URL:** <https://discourse.openondemand.org/t/ldap-result-code-200-network-error-tls-failed-to-verify-certificate-x509-certificate-relies-on-legacy-common-name-field-use-sans-instead/3996>\
**Category:** Get Help\
**Created:** [January 29, 2025, 5:09pm UTC](https://discourse.openondemand.org/t/ldap-result-code-200-network-error-tls-failed-to-verify-certificate-x509-certificate-relies-on-legacy-common-name-field-use-sans-instead/3996 "2025-01-29T17:09:23Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![reyjul](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/reyjul/32/2576_2.png) [@reyjul](https://discourse.openondemand.org/u/reyjul)\
**Post date:** [January 29, 2025, 5:09pm UTC](https://discourse.openondemand.org/t/ldap-result-code-200-network-error-tls-failed-to-verify-certificate-x509-certificate-relies-on-legacy-common-name-field-use-sans-instead/3996/1 "2025-01-29T17:09:23Z")

</div>

Hello,

I’m trying to install OOD on a Rocky Linux-9.4 but having issues making the authentication plugin dex to work with LDAP. I do see the login page when connecting via a browser (with https enabled) but get this error immediately after I click the “Log in to Open OnDemand” button:

> Internal Server Error  
> Login error: failed to connect: LDAP Result Code 200 “Network Error”: tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead

Here are the packages that were installed from the ondemand repository:

```auto
ondemand-release-web-4.0-1.el9.noarch
ondemand-runtime-4.0.3-1.el9.x86_64
ondemand-nodejs-4.0.3-1.el9.x86_64
ondemand-ruby-4.0.3-1.el9.x86_64
ondemand-passenger-6.0.23-1.ood4.0.3.el9.x86_64
ondemand-nginx-1.26.1-1.p6.0.23.ood4.0.3.el9.x86_64
ondemand-apache-4.0.3-1.el9.x86_64
ondemand-gems-4.0.0-1-4.0.0-1.el9.x86_64
ondemand-dex-2.41.1-1.el9.x86_64
ondemand-4.0.0-1.el9.x86_64

```

Here is my /etc/ood/config/ood\_portal.yml (removed commented lines for better readability and replaced our institution domain with mydomain for confidentiality):

```auto
---
listen_addr_port: 443
servername: ondemand.mydomain.fr
port: 443
ssl:
  - 'SSLCertificateFile "/etc/ssl/certs/star.mydomain.fr.crt"'
  - 'SSLCertificateKeyFile "/etc/ssl/certs/star.mydomain.fr.key"'
errorlog: 'error.log'
accesslog: 'access.log'
maintenance_ip_allowlist:
  - 172.27.6.5
dex:
  ssl: true
  http_port: "5556"
  https_port: "5554"
  tls_cert: /etc/ssl/certs/star.mydomain.fr.crt
  tls_key: /etc/ssl/certs/star.mydomain.fr.key
  connectors:
    - type: ldap
      id: ldap
      name: LDAP
      config:
        host: directory.rpbs.local:636
        insecureSkipVerify: false
        rootCA: /etc/openldap/certs/ca_server.pem
        bindDN: cn=admin,dc=rpbs,dc=local
        bindPW: somepassword
        userSearch:
          baseDN: ou=people,dc=rpbs,dc=local
          filter: "(objectClass=posixAccount)"
          username: uid
          idAttr: uid
          emailAttr: mail
          nameAttr: cn
          preferredUsernameAttr: uid
        groupSearch:
          baseDN: ou=groups,dc=rpbs,dc=local
          filter: "(objectClass=groupOfNames)"
          userMatchers:
            - userAttr: DN
              groupAttr: member
          nameAttr: cn

```

I tried playing with dex parameters by adding _https\_port_, _tls\_cert_, _tls\_key_ and _rootCA_ even though it seemed unecessary, but the ondemand-dex service is not serving on the 5554 port. Here is the resulting /etc/ood/dex/config.yaml file (the /opt/ood/ood-portal-generator/sbin/update\_ood\_portal command was launched multiple times):

```---
issuer: https://ondemand.mydomain.fr/dex
storage:
  type: sqlite3
  config:
    file: "/etc/ood/dex/dex.db"
web:
  http: localhost:5556
  tlsCert: "/etc/ssl/certs/star.mydomain.fr.crt"
  tlsKey: "/etc/ssl/certs/star.mydomain.fr.key"
telemetry:
  http: 0.0.0.0:5558
staticClients:
- id: ondemand.mydomain.fr
  redirectURIs:
  - https://ondemand.mydomain.fr/oidc
  name: OnDemand
  secret: 331703c4-91c2-49fd-9dbf-4b6c5f2f5a0c
connectors:
- type: ldap
  id: ldap
  name: LDAP
  config:
    host: directory.rpbs.local:636
    insecureSkipVerify: false
    rootCA: "/etc/openldap/certs/ca_server.pem"
    bindDN: cn=admin,dc=rpbs,dc=local
    bindPW: somepassword
    userSearch:
      baseDN: ou=people,dc=rpbs,dc=local
      filter: "(objectClass=posixAccount)"
      username: uid
      idAttr: uid
      emailAttr: mail
      nameAttr: cn
      preferredUsernameAttr: uid
    groupSearch:
      baseDN: ou=groups,dc=rpbs,dc=local
      filter: "(objectClass=groupOfNames)"
      userMatchers:
      - userAttr: DN
        groupAttr: member
      nameAttr: cn
oauth2:
  skipApprovalScreen: true
enablePasswordDB: false
frontend:
  dir: "/usr/share/ondemand-dex/web"
  theme: ondemand

```

On a side note, the OOD apache server is running behind a reverse proxy. I am not having issues authenticating to our LDAP server with other webservices like owncloud so I don’t really understand what this certificate issue is about. Is it related to the [mydomain.fr](http://mydomain.fr) or rpbs.local ?

Any help would be greatly appreciated.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [January 29, 2025, 5:18pm UTC](https://discourse.openondemand.org/t/ldap-result-code-200-network-error-tls-failed-to-verify-certificate-x509-certificate-relies-on-legacy-common-name-field-use-sans-instead/3996/2 "2025-01-29T17:18:27Z")

</div>

Hi and welcome!

It appears that `/etc/openldap/certs/ca_server.pem` is somehow bad, using legacy Common Name field. How did you get this file?

Google searching `golang TLS legacy Common Name field, use SANs instead` provides a lot of results - this one in particular talks about how to regenerate that rootCA.

> <https://stackoverflow.com/questions/64814173/how-do-i-use-sans-with-openssl-instead-of-common-name>

Further google search of `golang TLS legacy Common Name field` indicates that golang (the language Dex is written in) changed this at some point.

It seems you can either regenerrate the certificate or set the `GODEBUG="x509ignoreCN=0"` environment variable. We provide a systemd unit file somewhere that you could edit and add the envioronment variable.

---

<div class="post-metadata">

**Author:** ![reyjul](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/reyjul/32/2576_2.png) [@reyjul](https://discourse.openondemand.org/u/reyjul)\
**Post date:** [January 29, 2025, 6:12pm UTC](https://discourse.openondemand.org/t/ldap-result-code-200-network-error-tls-failed-to-verify-certificate-x509-certificate-relies-on-legacy-common-name-field-use-sans-instead/3996/3 "2025-01-29T18:12:25Z")

</div>

Hello @jeff.ohrstrom and thank you for your prompt response.

> [@jeff.ohrstrom](#):
>
> It appears that `/etc/openldap/certs/ca_server.pem` is somehow bad, using legacy Common Name field. How did you get this file?

Well, the self-signed certificate was generated years ago when the ldap server was deployed. I’m not sure it is an easy task to replace it. I will look into it.

> [@jeff.ohrstrom](#):
>
> It seems you can either regenerrate the certificate or set the `GODEBUG="x509ignoreCN=0"` environment variable. We provide a systemd unit file somewhere that you could edit and add the envioronment variable.

I tried adding the environment variable by dropping a .conf file in /etc/systemd/ondemand-dex.service.d:

```auto
[Service]
Environment=GODEBUG="x509ignoreCN=0"

```

And then did a systemctl daemon-reload.

But I’m still encountering the same error. Unfortunately I believe the GODEBUG=x509ignoreCN=0 flag was removed in Go 1.17 and dex is using 1.21.

---

<div class="post-metadata">

**Author:** ![reyjul](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/reyjul/32/2576_2.png) [@reyjul](https://discourse.openondemand.org/u/reyjul)\
**Post date:** [January 31, 2025, 4:50pm UTC](https://discourse.openondemand.org/t/ldap-result-code-200-network-error-tls-failed-to-verify-certificate-x509-certificate-relies-on-legacy-common-name-field-use-sans-instead/3996/4 "2025-01-31T16:50:01Z")

</div>

Looks like the LDAP server certificate was the root of the problem.

I just had to regenerate it by signing the CSR again with our root CA and add the SAN extension.

Login works now, thanks !

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex015/uploads/osc/original/2X/b/bae70bd0ed39a3ae769c2108155f4cb3e9da8385.png) [@system](https://discourse.openondemand.org/u/system)\
**Post date:** [July 30, 2025, 4:50pm UTC](https://discourse.openondemand.org/t/ldap-result-code-200-network-error-tls-failed-to-verify-certificate-x509-certificate-relies-on-legacy-common-name-field-use-sans-instead/3996/5 "2025-07-30T16:50:50Z")

</div>

Closed on July 30, 2025, 4:50pm UTC

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.