Docker Container Zertifikate - LDAPS

lokaurazin

Cadet 4th Year
Registriert
Apr. 2008
Beiträge
103
Hallo zusammen,

kann mir jemand bitte einen Tipp geben, wie ich meinen Docker Container überreden kann, die Zertifikate des Hosts zu verwenden?

Was ich tun möchte: Einen Redmine Container die AD Authentifizierung über LDAPS verwenden lassen.
Der Host basiert auf photon OS. Die AD läuft auf einem Windows Server 2012 R2 Domaincontroller. Docker verwalte ich mit Portainer.

Was funktioniert:
1) LDAP unverschlüsselt funktioniert problemlos.
2) Ein "openssl s_client -connect xxx.xxx.local:636 -showcerts" am Host ergibt:
Code:
CONNECTED(00000003)
depth=1 DC = local, DC = xxx, CN = xxx-CA
verify return:1
depth=0 CN = xxx.xxx.local
verify return:1
---
Certificate chain
 0 s:CN = xxx.xxx.local
   i:DC = local, DC = xxx, CN = xxx-CA
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
---
Server certificate
subject=CN = xxx.xxx.local

issuer=DC = local, DC = xxx, CN = xxx-CA

---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Peer signing digest: SHA1
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2138 bytes and written 519 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-SHA384
    Session-ID: xxx
    Session-ID-ctx:
    Master-Key: xxx
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1626334979
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---

Im Container ergibt ein "openssl s_client -connect xxx.xxx.local:636 -showcerts" aber:
Code:
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 315 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---


Meine yaml:
Code:
version: '2'
services:
  mariadb:
    image: docker.io/bitnami/mariadb:10.3
    restart: unless-stopped
    networks:
      - redmine
    environment:
      - ALLOW_EMPTY_PASSWORD=yes
      - MARIADB_USER=bn_redmine
      - MARIADB_DATABASE=bitnami_redmine
    volumes:
      - 'bitnami_mariadb_data:/bitnami'
  redmine:
    image: docker.io/bitnami/redmine:4
    restart: unless-stopped
    networks:
      - redmine
    environment:
      - REDMINE_DB_USERNAME=testredmine
      - REDMINE_DB_NAME=testredmine
    ports:
      - '3000:3000'
    volumes:
      - 'bitnami_redmine_data:/bitnami'
      - '/ect/ssl/certs/:/etc/ssl/certs/'
    depends_on:
      - mariadb
volumes:
  bitnami_mariadb_data:
    driver: local
  bitnami_redmine_data:
    driver: local
networks:
  redmine:
    name: redmine

Was kann ich tun?
 
Vermutung: openssl erwartet die Root CAs wohl in einem anderen Verzeichnis, als du denkst. Im Container mit
Code:
openssl version -d
nachschauen, wo die Zertifikate erwartet werden und entsprechend symlinks oder mounts einbauen.

Hab hier gerade nur ein Uralt-Bastelsystem zur Hand, aber da sagt mir openssl, es sucht die Zertifikate in "/usr/lib/ssl/" und da gibt es einen symlink "certs" nach "/etc/ssl/certs".
 
  • Gefällt mir
Reaktionen: lokaurazin und konkretor
Ich kenne mich zwar mit den Sachen nicht aus, aber im Redmine-Container ist schon irgendwo konfiguriert, welche Certs es nutzen soll?
 
kartoffelpü schrieb:
welche Certs es nutzen soll?
Wahrscheinlich nutzt Redmine im Endeffekt openssl und das findet laut TE die RootCAs im Container nicht. Daher macht es Sinn, erstmal an der Stelle anzusetzen. Falls Redmine auf eine andere Cryptolibrary setzt, muss natürlich ggf. weitergesucht werden... die Ursache dürfte dann aber dieselbe sein.
 
KillerCow schrieb:
Vermutung: openssl erwartet die Root CAs wohl in einem anderen Verzeichnis, als du denkst. Im Container mit
Code:
openssl version -d
nachschauen, wo die Zertifikate erwartet werden und entsprechend symlinks oder mounts einbauen.

Hab hier gerade nur ein Uralt-Bastelsystem zur Hand, aber da sagt mir openssl, es sucht die Zertifikate in "/usr/lib/ssl/" und da gibt es einen symlink "certs" nach "/etc/ssl/certs".
Super Hinweis. Du hast recht. Das Volume sollte auf /etc/ssl/certs/:/usr/lib/ssl/certs/ konfiguriert sein. Jetzt sieht er es.
Die Hürde an der ich gerade bin ist, dass ein update-ca-certificates im Container für die Zertifikate ergibt:
Code:
rehash: warning: skipping xxx.cer,it does not contain exactly one certificate or CRL


kartoffelpü schrieb:
Ich kenne mich zwar mit den Sachen nicht aus, aber im Redmine-Container ist schon irgendwo konfiguriert, welche Certs es nutzen soll?
Nicht direkt in Redmine. Der oberhalb genannte Befehl registriert die Zertifikate für openssl.


edit: Die Meldung in Bezug auf das Zertifikat soll wohl unkritisch sein. Leider funktioniert es noch immer nicht, dass er eine LDAPS Verbindung aufbauen kann...
 
Zuletzt bearbeitet:
lokaurazin schrieb:
dass ein update-ca-certificates im Container
Das willst du auch nicht im Container machen, wenn es mit dem "Original" des Hosts verbunden ist. Und soweit ich das im Kopf habe, holt/verlinkt "update-ca-certificates" Zertifikate aus einem anderen Verzeichnis nach "/etc/ssl/certs". Sie einfach zu, dass deine benötigten Zertifikate auf dem Host hinterlegt sind.

Aber dazu gibt es bestimmt sinnvollere/sauberere Lösungen im Netz. Du wirst nicht der Einzige sein, der in einem Container RootCAs für openssl braucht ;)
 
  • Gefällt mir
Reaktionen: lokaurazin
Kurzes Update: Binde ich das Volume inkl. config ein, funktioniert es
/etc/ssl/:/usr/lib/ssl/
Also config war fehlerhaft...
 
Zurück
Oben