Could not authenticate you from Ldapmain because "Wrong argument type string (expected openssl/x509)"

How to Use GitLab Self-managed
1

Enable verify_certificates in LDAPS connection to FreeIPA

Describe your question in as much detail as possible:

I am using FreeIPA 4.11.1 for LDAP authentication with GitLab 16.9. I have generated FreeIPA CA TLS certs for the https connection to the GitLab server and works great. All my web clients have the ca.crt installed and are able to verify the gitlab server just fine. I am trying to use the same certs on the gitlab host to verify the ldaps connection that the gitlab server makes to the FreeIPA server.

With verify_certificates set to false, all works well.
With verify_certificates set to true, I get the following error:

Could not authenticate you from Ldapmain because “Wrong argument type string (expected openssl/x509)”.

Here’s my config:

external_url 'https://gitlab.example.org'
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
    main:
      label: 'FreeIPA'
      hosts: [['idm1.example.org', 636],['idm2.example.org', 636]]
      uid: 'uid'
      bind_dn: 'uid=gitlab-svc,cn=users,cn=accounts,dc=example,dc=org'
      password: '**********'
      encryption: 'simple_tls'
      verify_certificates: true
      active_directory: false
      base: 'dc=example,dc=org'
      user_filter: (objectClass=posixaccount)
      group_base: 'cn=groups,cn=accounts,dc=example,dc=org'
      tls_options:
        ca_file: '/etc/gitlab/ssl/ca.crt'
        cert: '/etc/gitlab/ssl/gitlab.example.org.crt'
        key: '/etc/gitlab/ssl/gitlab.example.org.key'

EOS
nginx['ssl_client_certificate'] = "/etc/gitlab/ssl/ca.crt"
nginx['ssl_certificate'] = "/etc/gitlab/ssl/#{node['fqdn']}.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/#{node['fqdn']}.key"
letsencrypt['auto_renew'] = false

Here is the TLS connection to my FreeIPA LDAP server:

root@gitlab:~# openssl s_client idm1.example.org:636
CONNECTED(00000003)
depth=1 O = EXAMPLE.ORG, CN = Certificate Authority
verify return:1
depth=0 O = EXAMPLE.ORG, CN = idm1.example.org
verify return:1
---
Certificate chain
 0 s:O = EXAMPLE.ORG, CN = idm1.example.org
   i:O = EXAMPLE.ORG, CN = Certificate Authority
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar  6 19:10:38 2024 GMT; NotAfter: Mar  7 19:10:38 2026 GMT
 1 s:O = EXAMPLE.ORG, CN = Certificate Authority
   i:O = EXAMPLE.ORG, CN = Certificate Authority
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar  6 19:09:11 2024 GMT; NotAfter: Mar  6 19:09:11 2044 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
subject=O = EXAMPLE.ORG, CN = idm1.example.org
issuer=O = EXAMPLE.ORG, CN = Certificate Authority
---
Acceptable client certificate CA names
O = EXAMPLE.ORG, CN = Certificate Authority
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3084 bytes and written 414 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
closed

Here is the certificate on gitlab that I’m using to talk to the LDAP server:

root@gitlab:/etc/gitlab/ssl# openssl x509 -in gitlab.example.org.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 268369921 (0xfff0001)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O = EXAMPLE.ORG, CN = Certificate Authority
        Validity
            Not Before: Mar  6 22:28:27 2024 GMT
            Not After : Mar  7 22:28:27 2026 GMT
        Subject: O = EXAMPLE.ORG, CN = gitlab.example.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d3:85:1d:84:e2:f9:12:31:cb:a6:61:7b:cc:8c:
                    .
                    . 
                    . 
                    a3:1b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                2B:20:30...
            Authority Information Access:
                OCSP - URI:http://ipa-ca.example.org/ca/ocsp
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://ipa-ca.example.org/ipa/crl/MasterCRL.bin                CRL Issuer:
                  DirName:O = ipaca, CN = Certificate Authority
            X509v3 Subject Key Identifier:
                4F:D6:DB....
            X509v3 Subject Alternative Name:
                DNS:gitlab.example.org, othername: UPN::http/gitlab.example.org@EXAMPLE.ORG, othername: 1.3.6.1.5.2.2::<unsupported>
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        75:0d:15:41:b3:22:ca:7f:56:a7:23:a7:1b:af:9b:33:1e:b7:
        .
        . 
        . 
        99:c4:b9:60:ad:76
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

So any help would be appreciated, I’m extremely new to GitLab and understand the basics of TLS and certificates and hope that someone might know what I’m doing wrong here. I suspect it might be with the certs but not sure how to proceed.

Thank you!

Versions

Please select whether options apply, and add the version information.

Versions

2

Do you have the CA certificate imported on the Gitlab server that verifies the FreeIPA certificates? If not, then would be good to do this. On Debian/Ubuntu, copy the CA certificate to /etc/ssl/certs and then run update-ca-certificates. If this is an RPM-based distro like RHEL, copy to /etc/pki/ca-trust/source/anchors, and then run update-ca-trust. That should sort it out.

1 Like
3 
      tls_options:
        ca_file: '/etc/gitlab/ssl/ca.crt'

I’d thought that would cover gitlab knowing about the CA but stranger things have happened…

This is a RHEL based distro and updated the CA trust. Unfortunately, that didn’t fix the issue and I am still getting the error. ]I think that trust was updated when the host GitLab host joined the IPA domain. I should have mentioned that earlier, my apologies. Any other ideas?

I have commented out the host key and certificate file leaving just the CA and that seemed to work but that doesn’t seem right to me. shrug

4

Adding the CA file in the LDAP config section is also valid, since it’s for verifying the certificates when connecting to the FreeIPA server and the certificates in use there. Although I would expect when using TLS, that there should be some certs from the client side (so Gitlab in this instance). Not sure why that didn’t work to be honest, especially if those certs are verified by the same CA responsible for the FreeIPA certs.

1 Like
5

Got it figured out. cert and key are supposed to be the actual cert and key in yaml format. Once I plugged those in, it all worked out great. I can read the documentation, but it’s up to me to understand it. facepalm

  tls_options:
    ca_file: '/etc/gitlab/ssl/ca.crt'
    cert: |
          -----BEGIN CERTIFICATE-----
          MIIFLjCCA5agAwIBAgIED/8AATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtD
         ...
          yranNGqzKZOfUY4287sPI1EWUBMbeP/0np9uDZnEuWCtdg==
          -----END CERTIFICATE-----
    key: |
          -----BEGIN PRIVATE KEY-----
          MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDThR2E4vkSMcum
          ....
          bEeROPPjBrTvg3INGy3ayt2SIQ==
          -----END PRIVATE KEY-----
2 Likes