LDAPS not working with ED25519 cert from version 2024.6.0

**Describe the bug**
Ldaps connections do not work with ed25519 starting at 2024.6.0

**To Reproduce**
Steps to reproduce the behavior:

1. Create and import ED25519 cert into authentik
2. Select above cert for ldap
3. Execute ``ldapsearch -x -H ldaps://authentik.local -D "cn=username,ou=users,DC=ldap,DC=authentik,DC=go" -W -v``
4. See error

**Expected behavior**
ldap initialization

**Screenshots**

\-

**Logs**

Ldap log on 2024.4.3

```
root@server:~# ldapsearch -x -H ldaps://authentik.local -D "cn=username,ou=users,DC=ldap,DC=authentik,DC=go" -W -v
ldap_initialize( ldaps://authentik.local:636/??base )
Enter LDAP Password:
filter: (objectclass=*)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
objectClass: top
entryDN:
supportedLDAPVersion: 3
supportedCapabilities: 1.2.840.113556.1.4.800
supportedCapabilities: 1.2.840.113556.1.4.1791
supportedCapabilities: 1.2.840.113556.1.4.1670
supportedCapabilities: 1.2.840.113556.1.4.1880
supportedCapabilities: 1.2.840.113556.1.4.1851
supportedCapabilities: 1.2.840.113556.1.4.1920
supportedCapabilities: 1.2.840.113556.1.4.1935
supportedCapabilities: 1.2.840.113556.1.4.2080
supportedCapabilities: 1.2.840.113556.1.4.2237
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.10
supportedControl: 1.2.840.113556.1.4.474
supportedControl: 1.2.840.113556.1.4.319
subschemaSubentry: cn=subschema
namingContexts: dc=ldap,dc=authentik,dc=go
rootDomainNamingContext: dc=ldap,dc=authentik,dc=go
vendorName: goauthentik.io
vendorVersion: authentik LDAP Outpost Version 2024.4.3

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
```

Ldap log on 2024.6.0

```
root@server:~# ldapsearch -x -H ldaps://authentik.local -D "cn=username,ou=users,DC=ldap,DC=authentik,DC=go" -W -v
ldap_initialize( ldaps://authentik.local:636/??base )
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
```

Docker Logs on 2024.6.0

```
root@docker:/opt/authentik# docker logs authentik-ldap-1 -f
{"event":"Loaded config","level":"debug","path":"inbuilt-default","timestamp":"2024-07-31T18:44:41Z"}
{"event":"Loaded config from environment","level":"debug","timestamp":"2024-07-31T18:44:41Z"}
{"event":"not enabling debug server, set `AUTHENTIK_DEBUG` to `true` to enable it.","level":"info","logger":"authentik.go_debugger","timestamp":"2024-07-31T18:44:41Z"}
{"event":"Successfully connected websocket","level":"info","logger":"authentik.outpost.ak-ws","outpost":"...","timestamp":"2024-07-31T18:44:41Z"}
{"event":"Fetching certificate and private key","level":"info","logger":"authentik.outpost.cryptostore","timestamp":"2024-07-31T18:44:42Z","uuid":"..."}
{"event":"initialised direct binder","level":"info","logger":"authentik.outpost.ldap.binder.direct","timestamp":"2024-07-31T18:44:42Z"}
{"event":"Update providers","level":"info","logger":"authentik.outpost.ldap","timestamp":"2024-07-31T18:44:42Z"}
{"event":"Starting LDAP SSL server","level":"info","listen":"0.0.0.0:6636","logger":"authentik.outpost.ldap","timestamp":"2024-07-31T18:44:42Z"}
{"event":"Starting LDAP server","level":"info","listen":"0.0.0.0:3389","logger":"authentik.outpost.ldap","timestamp":"2024-07-31T18:44:42Z"}
{"event":"Starting Metrics server","level":"info","listen":"0.0.0.0:9300","logger":"authentik.outpost.metrics","timestamp":"2024-07-31T18:44:42Z"}
2024/07/31 18:44:48 handleConnection ber.ReadPacket ERROR: tls: peer doesn't support any of the certificate's signature algorithms
2024/07/31 18:44:58 handleConnection ber.ReadPacket ERROR: tls: peer doesn't support any of the certificate's signature algorithms
2024/07/31 18:44:59 handleConnection ber.ReadPacket ERROR: tls: peer doesn't support any of the certificate's signature algorithms
```

**Version and Deployment (please complete the following information):**

- authentik version: starting 2024.6.0
- Deployment: docker-compose

**Additional context**
Some informations from the logs were masked.

Also I am unsure if this is specifically related to the ed25519 algorithm.