Forum Debian Users Gang

Czekaj, możesz mi wyjaśnić? Certyfikat CA am m wrzucić na klientów i za jego pomocą wygenerować certyfikaty klienta?

Bo na stacji klienckiej mam wygenerowany CA własny i przez niego wygenerowane pozostałe. Nie rozumiem gdzie popełniam błąd, gdyż JXplore po dodaniu certyfikatów w takiej konfiguracji działa poprawnie

Uporządkujmy trochę wiedze, bo raz piszesz klucz publiczny a raz certyfikat.

Mówimy tylko o linuksach. Rozumiem że certyfikat CA wygenerowany na serwerze. Mam przerzucić na stacje kliencka i z jego pomocą wygenerować certyfikaty klienta. Odnoszę się ciągle do dokumentacji [html]https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-tls[/html], bo tam jest wszystko jasne, co jest certyfikatem co kluczem.

Obecnie mam sytuację, iż wygenerowałem wszystko zgodnie z dokumentacja na serwerze. To samo zrobiłem na kliencie. A z tego co rozumiem po tym co piszesz, to powinienem przenieść certyfikat ca serwer ana klient ai z jego pomocą wygenerować resztę. Tak?

Co do twojej weryfikacji gdy weryfikuje certyfikat który mam obecnie:

openssl verify -CAfile /etc/ssl/certs/host.pem /etc/ssl/certs/cacert.pem 
CN = Przykladowa Firma
error 18 at 0 depth lookup: self signed certificate
error /etc/ssl/certs/cacert.pem: verification failed

Gdy pobrałem z serwera jego CA i weryfikuje:

openssl verify -CAfile /etc/ssl/certs/host.pem /etc/ssl/certs/cacert.pem 
CN = Przykladowa OD Firma
error 18 at 0 depth lookup: self signed certificate
error /etc/ssl/certs/cacert.pem: verification failed

CN się różni tyko.

Ok taki mam wynik:

user@5CG6326QQ5:~$ openssl verify -CAfile /etc/ssl/certs/cacert.pem /etc/ssl/certs/host.pem 
/etc/ssl/certs/host.pem: OK
user@5CG6326QQ5:~$ openssl verify -CAfile cacert.pem /etc/ssl/certs/host.pem 
CN = 5CG6326QQ5, O = Firma Przykadowa
error 20 at 0 depth lookup: unable to get local issuer certificate
error /etc/ssl/certs/host.pem: verification failed

Pierwszy to ten co mam, a drugi to pobrany CA z serwera.

Wychodzi na to, że źle wygenerowałem certyfikaty dla klienta, bo użyłem przez niego wygenerowanego CA zamiast CA serwera, racja? Więc muszę wygenerować certyfikaty dla hosta z użyciem tego CA pobranego.

Tylko pytanie, dlaczego na tej konfiguracji w JXplore zadziałało?

host.pem to certyfikat hosta wygenerowany na stacji hosta za pomoca:

certtool --generate-certificate --load-privkey /etc/ssl/private/host.pem --load-ca-certificate /etc/ssl/certs/cacert_hosta.pem --load-ca-privkey /etc/ssl/private/cakey_hosta.pem --template /etc/ssl/host.info --outfile /etc/ssl/certs/host_slapd_cert.pem

Zmieniłem cacert.pem. Ten w katalogu ssl/certs jest wygenerowany lokanie na maszynie. Ten w katalogu . jest wygenerowany na serwerze i pobrany na hosta.

Pierwszy jest zgodny bo CA wygenerowanym na hoście wygenerowałem certyfikat klienta.
Drugi jest niezgodny bo certyfikatem CA serwera sprawdzałem certyfikat hosta, który był wygenerowany na pomocą CA hosta.

Rozumiem teraz że muszę na hosta wrzucić certyfikat CA serwera i jego klucz (na pewno klucz prywatny mam przesłać?) aby wygenerować certyfikat hosta. Wtedy będa w stanie się zweryfikować?

Ostatnio edytowany przez Krump (2019-07-10 14:59:00)

Host Pem to certyfikt hosta wygenerowany za pomoca cacert.pem. Każdy ma swój. Host ma sœój, serwer ma swój.

OK, słuchaj zrobiłem tak:
Na serwerze certyfikujacym ze swoim Ca wygenerowałem certyfikat dla hosta z pomocą komendy:

certtool --generate-certificate --load-privkey /etc/ssl/private/odps03_slapd_key.pem --load-ca-certificate /etc/ssl/certs/cacert_odps03.pem --load-ca-privkey /etc/ssl/private/cakey_odps03.pem --template /etc/ssl/hosts/5CG6326QQ5.info --outfile /etc/ssl/hosts/5CG6326QQ5_slapd_cert.pem

Gdzie --template /etc/ssl/hosts/5CG6326QQ5.info są to informacje hosta, reszta nazw plików zgadza się loicznie z ich przeznaczeniem, tj cakey_odps03 to klucz prywatny certyfikatu CA a odps03_slapd_key.pem to klucz prywatny serwera.

Tak wygenerowany certyfikat, wysłałem do host ai wrzuciłem do /etc/ssl/certs, a nastewpnie przeprowadziłem weryfikację:

openssl verify -CAfile /etc/ssl/certs/cacert_odps03.pem /etc/ssl/certs/5CG6326QQ5_slapd_cert.pem
/etc/ssl/certs/5CG6326QQ5_slapd_cert.pem: OK

Gdzie cacert_odps03.pem jest certyfikatem ca przesłanym z serwera, a 5CG6326QQ5_slapd_cert.pem jest świeżo przesłanym certyfikatem.

Wiec w sumie po bożemu wydałem certyfikat dla klienta.
Jednak do połączenia ldapsearch dalej nie dochodzi

Ostatnio edytowany przez Krump (2019-07-11 12:30:07)

Ja bym zrobił tak:
Generuję klucz i cert CA, certyfikat CA kopiuję między maszynami - ma być wspólny.

Generuję certyfikaty dla serwerów - każdy o unikalnej nazwie serwera.
Podpisuję je kluczem CA, i sprawdzam poprawność każdego certu serwera z certyfikatem CA.
Generuję certyfikaty klientów, podpisuję je kluczem CA, sprawdzam podpis z certyfikatem CA i rozsyłam po klientach.

W ten sposób mam porządek i musi to działać ze wszystkimi usługami używającymi SSL w obrębie prywatnego CA.

Razem jest to może godzinka-dwie roboty, którą trzeba kontrolować na każdym etapie pośrednim.


Chociaż nie ukrywam, że do LDAPa mam spore uczulenie, wolę bazy SQL, które robią dokładnie to samo.
Do vcard i kalendarza jest np Davical, Baikal czy Radicale, które pięknie gadają
z Thunderbirdem, Outlookiem, IPhonem i systemowym kalendarzem Androida. ;)

PS:
Generowanie certów możesz sobie oskrypcić i używać czystego openssl.
Z resztą w źródłach openssl masz gotowe skrypty CA.pl i CA.sh, mogą posłużyć za inspirację.
Podobnie z resztą jak easy-rsa.

Ostatnio edytowany przez Jacekalex (2019-07-12 10:45:39)

LDAP do telefonii VOIP?

Warto tak sobie życie utrudniać?
Asterisk najlepiej i najszybciej chodzi z Mysqlem Postrgresql, lub Radiusem, Freeswitch z Postgresql, ODBC lub Radiusem.

Samba ewentualnie, ale w Sambie lepiej trzymać samą autoryzację i oprzeć ją na najbardziej niezawodnym elemencie systemu Linux/UNIX/BSD:
https://wiki.samba.org/index.php/Authenticating_Domain_Users_Using_PAM

Pakując LDAP do Voip i Samby zrobiłeś sobie najpiękniejszy SPOF w najbardziej krytycznym miejscu, jakie mogłeś wymyślić.

Jeżeli masz to w sieci LAN, to ja bym na razie awaryjnie zdjął szyfrowanie, a docelowo podziękował LDAPowi za uwagę.

Vcard w czasach cegłofonów da się  dużo sensowniej rozwiązać z wykorzystaniem https.
Autoryzacja to najlepiej PAM,  Radius i SQL.
Tam masz tyle opcji i bibliotek, ze zawsze masz spore pole manewru, jak jakiś demon się skicha.
Np nie przypominam sobie jakichś problemów z Mysql czy Postgresem, FreeRadius też jest dosyć przewidywalny (chociaż czasem kiepsko znosi aktualizacje Openssl).

Ostatnio edytowany przez Jacekalex (2019-07-12 12:25:58)

Ma być szyfrowanie?

To zrób tunel OpenVPN, OpenSSH  czy Stunnel, i niech nieszyfrowany ldap fruwa w tym tunelu, jak sam ma problemy z szyfrowaniem.

Względnie jeśli LDAP wcześniej działał z szyfrowaniem a obecnie przestał, to może jakiś upgrade lub downgrade pomoże?

Próbowałeś użyć innego systemu do tego LDApa, np CentOSa?

Może po prostu Openldap był kompilowany z inną wersją biblioteki SSL niż masz obecnie w systemie, i dlatego są takie kłopoty.

Czy ten ldap nigdy nie chodził po SSL, czy chodził i zdechł po jakiejś aktualizacji?

Setek klientów do LDAPa?

To pakuj tam Windows Serwer, LDAP to pomysł Microsoftu, OpenLDAP to jest proteza, niby ma działać, ale w miarę umierania Windowsa, ani Linux ani Android, ani Apple za nim nie tęsknią, co widać choćby w Twoich ostatnich problemach z szyfrowaniem.

Z resztą widziałeś jakieś usługi Googla, FB, Twittera, Dropbox czy innych podobnej wagi operatorów, którzy by mieli cokolwiek wspólnego z LDAPem?
A przecież mają wizytówki Vcard, mają książki adresowe, mają wirtualne dyski, wszystko schowane za dosyć solidną autoryzacją.
To samo operatorzy Voip obrabiający nie kilkuset, ale kilkanaście albo nawet kilkaset tysięcy klientów.

O Komunikatorach typu Signal, Telegram, Hangouts czy WhatsApp nie wspominając.

Ostatnio edytowany przez Jacekalex (2019-07-12 14:49:33)

Może mam config zwalony? Robiłem różne próby konfiguracji aby rozwiązać problem, dlatego tye komentarzy.

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE    dc=example,dc=company,dc=pl
URI     ldap://localhost ldaps:/// ldaps://odps03:636

#SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
HOST            odps03.example.company.pl
PORT            636
TLS_CACERT      /etc/ssl/certs/cacert.pem #ca-certificates.crt
#TlS_CERT       /etc/ssl/certs/odps03_slapd_cert.pem 
#TLS_KEY                internal:secret
TLS_REQCERT     never #DEMAND #ALLOW

Ostatnio edytowany przez Krump (2019-07-15 12:08:36)

Więcej kientów... Nie zagłębiając się, po prostu nie ma zezwolenia na windows w tej dziedzinie i tyle.

Wygląda na to, że to nie jest problem stricte z certyfikatami na ten moment tylko z samym połączeniem do serwera. Coś jest nie tak w konfig, bo właczyłem nieszyfrowane połączyć i próbowałem się połączyć do ldapa i miałem ten sam błąd:

openssl s_client -connect odps03:636
CONNECTED(00000005)
depth=1 CN = Przykładowa Firma
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:CN = odps03, O = Przykładowa Firma
   i:CN = Przykładowa Firma
 1 s:CN = Przykładowa Firma
   i:CN = Przykładowa Firma

Szukam informacji co dokadnie znaczy ten błąd albo jak lepiej debugować:

ldap_err2string
ldap_start_tls: Can't contact LDAP server (-1)

Niestety nie za bardzo rozumiem o co ci chodzi z połączeniem przez  gdb lub strace,
Wszyscy wskazują ze to problem z wyłączona usługą abo nie otwartym portem, a u mnie i to i to działa poprawnie, dlatego szukam głębiej. Nie jestem z tych co byle problem pytają tylko raczej z tych co szukają aż się zesrają.

Ostatnio edytowany przez Krump (2019-07-17 14:40:40)