Certyfikat Letsencrypt wewnątrz sieci firmowej

[Kaziu]

Witam,

 

Posiadam serwer WWW wewnątrz sieci firmowej, na którym stoi chmura NextCloud. Każdy pracownik może wejść na swoje konto wpisując w przeglądarce adres 192.168..... Niestety przeglądarki zgłaszają problem braku certyfikatu co jest dość uciążliwe dla ludzi. Zastanawiam się jak to obejść i czy da się w jakiś sposób podpiąć darmowe letsencrypt?

[oui]

Jak masz jakąś publiczną domenę to możesz pobrać certyfikat przez DNS challenge i podpiąć domenę/certyfikat do NC

[Kaziu]

Ale ten serwer WWW nie jest wystawiony na zewnątrz, komputery łączą się z nim po adresie IP. Myślisz, że zadziała?

[Mruczek]

Pamiętaj, że certyfikat SSL jest wystawiany na FQDN i weryfikowana jest właśnie nazwa domenowa wpisana w pasku adresu z nazwą z certyfikatu. Musiałbyś kombinować z użyciem domeny "zewnętrznej" wewnątrz LANu i weryfikować ją w LE jak kolega wyżej napisał (DNS challenge), lub postawić własne PKI, "rozdać" certyfikat root na końcówki itd.

[kix]

1. Kupić domenę lub jesli jest istniejaca to jej uzyc.
2. Kupic hosting/serwer wspierajacy letsencrypt wystawiajacy wildcardy.
3. Podpiac domene do hostingu i skonfigurowac wystawianie wildcarda.
4. Do domeny dodac rekord A owncloud.domena.pl. kierujacy na 192.168.X.X - czyli adres IP nextclouda w sieci lokalnej.

5. Skopiowac certyfikat z hostingu na serwer lokalny i zainstalowac do ownclouda razem z subdomena.

Jak serwer lokalny ma dostep do internetu to teoretycznie mozna pominac posiadanie hostingu, zainstalowac tam acme2 do letsentencrypta i tylko kupic domene u jakiegos dostawcy, ktore daje do domeny opcje uzywania jego nameserverow.

Uzytkownicy beda mieli i certa i dostep po domenie.

Tansza opcja to po prostu wyslac wszystkim pracownikom obecny cert z ownclouda i niech go dodadza do zaufanych.

Edytowane 7 Grudnia 2021 przez kix

[Poziomecki]

2 godziny temu, kix napisał:

1. Kupić domenę lub jesli jest istniejaca to jej uzyc.
2. Kupic hosting/serwer wspierajacy letsencrypt wystawiajacy wildcardy.
3. Podpiac domene do hostingu i skonfigurowac wystawianie wildcarda.
4. Do domeny dodac rekord A owncloud.domena.pl. kierujacy na 192.168.X.X - czyli adres IP nextclouda w sieci lokalnej.

5. Skopiowac certyfikat z hostingu na serwer lokalny i zainstalowac do ownclouda razem z subdomena.

Jak serwer lokalny ma dostep do internetu to teoretycznie mozna pominac posiadanie hostingu, zainstalowac tam acme2 do letsentencrypta i tylko kupic domene u jakiegos dostawcy, ktore daje do domeny opcje uzywania jego nameserverow.

Uzytkownicy beda mieli i certa i dostep po domenie.

Tansza opcja to po prostu wyslac wszystkim pracownikom obecny cert z ownclouda i niech go dodadza do zaufanych.

 

Jeden minus tego patentu. Musisz co te 2-3 miesiące przekopiowywać certyfikat z hostingu.

 

Już lepiej kupić 29zł / rok na jakiś cert, który będzie na rok. Koszt mniejszy roczny niż takiego hostingu i mniej zabawy.

 

Darmowym rozwiązaniem może być jedynie własny urząd certyfikacji wewnątrz sieci i wystawienie certa np. na 10 lat i po problemie.

 

Pytanie do autora jeszcze czy samopodpisany certyfikat ci nie wystarczy. Raz użytkownicy tylko zaakceptują wyjątek i tyle.

[psz]

Let's Encrypt z weryfikacją typu DNS jest jednak najwygodniejszym sposobem. Serwer lokalny musi mieć tylko dostęp do edycji DNS (wtyczek do różnych operatorów DNS jest mnóstwo).

 

Na linuksa: certbot, acme.sh

Na Windows: Certify The Web

 

Alternatywnie: darmowy certyfikat z Buypass, choć ważny tylko pół roku, jednak mniej ręcznych podmianek.

[Spoofy]

Alternatywnie można wygenerować LET na serwerze zewnętrznym, następnie post-hook'iem np. via scp przepchać certyfikat na docelową maszynę - z powodzeniem wykonywałem takie setup'y, lecz pamiętajmy o tym, że lepiej byłoby zarządzić taką siecią wewnętrzną, tzn. każdemu w sieci zapodać po bożemu własny CA i z tego poziomu wygenerować certyfikat

Inna opcja - tak jak @Mruczekwspomniał, certyfikat jest generowany na domenę - zatem można po bożemu kupić komercyjny certyfikat na domenę i ustawić lokalny DNS wskazujący na dany adres wewnątrz sieci. Edit - czyli w sumie dokładnie tak jak opisał to @Poziomecki.

[psz]

8 minut temu, Spoofy napisał:

każdemu w sieci zapodać po bożemu własny CA i z tego poziomu wygenerować certyfikat

 

Może jestem beztroski przez istnienie Let's Encrypt, ale sądzę, że publiczny certyfikat jest najelegantszym rozwiązaniem, bo nie trzeba bawić się w prywatne CA i instalować certyfikat na końcówkach. Let's Encrypt (i inne) po prostu działają out-of-the-box na każdym systemie/przeglądarce/konsoli/tosterze wyjętym z pudełka.

[st220]

Najlepiej przez dns, jest wiele pluginów aby korzystać z publicznych dns jak np. cloudflare czy ovh. Wtedy nie ma znaczenia czy miejsce korzystania nie jest publiczne.

[Kaziu]

Mam domenę, którą mogę podpiąć i samo wygenerowanie certyfikatu nie byłoby problemem. Tylko komputery w sieci i tak łączą się z nc poprzez adres IP. W sieci używam jeszcze piHole jako wewnętrzny DNS. Tylko nie wiem jak przekierować ruch z domeny na wewnetrzny adres IP. Nawet nie wiem czy w piHole jest taka możliwość.

[Poziomecki]

6 godzin temu, psz napisał:

 

Może jestem beztroski przez istnienie Let's Encrypt, ale sądzę, że publiczny certyfikat jest najelegantszym rozwiązaniem, bo nie trzeba bawić się w prywatne CA i instalować certyfikat na końcówkach. Let's Encrypt (i inne) po prostu działają out-of-the-box na każdym systemie/przeglądarce/konsoli/tosterze wyjętym z pudełka.

 

Bardzo dużo firm i organizacji stosuje własne CA i własne certyfikaty do sieci odizolowanych i wewnętrznych. Nie jest to nic złego a bardzo często rozwiązuje to naprawdę bardzo dużo problemów.

 

@Spoofyoczywiście że można, ale trzeba to monitorować moim zdaniem (ważność certów) bo jak "coś" pójdzie nie tak to jest problem i bardzo często jakiemuś kierownictwu które jest nietechniczne nie wytłumaczysz dlaczego wszyscy dostali żółty trójkąt i że to wcale nie jest atak hakjerów. Własne CA na wirtualce i ogarnięcie tego to nie powinno zająć dużo czasu na ustawienie a zwłaszcza że bardzo dużo jest oprogramowań open source, więc koszt wynosi 0zł.

 

Rozwiązań jak widać jest wiele. @Kaziupowinieneś rozpisać sobie tak naprawdę rozwiązania, rozplanować, spisać za i przeciw i wybrać na spokojnie rozwiązanie. Możesz nawet jak potrzebujesz na szybko pobawić się w LE a później po prostu ewentualnie przetestować inne rozwiązania na jakiejś testówce.

 

@Kaziu przekierowanie ustawisz po prostu na serwerze DNS gdzie masz domenę podpiętą ustawiając rekord A na wewnętrzny 192.168.1.xxx. Wszyscy z sieci będą przekierowywani na ten adres. Sprawdź tylko czy nie koliduje to z jakimiś rekordami w pihole.

[Kaziu]

Domeny trzymam w cloudflare, ale nigdy nie sprawdzałem czy można tam przypisać adres z tej puli (tzn. 192...). Jeśli to zadziała to problem będzie rozwiązany

[psz]

Można. Nic nie stoi na przeszkodzie, żebyś zrobił rekord w DNS, np. nextcloud.mojafirma.pl z adresem 192.168.42.42.

[spex]

8 godzin temu, Spoofy napisał:

[...], lecz pamiętajmy o tym, że lepiej byłoby zarządzić taką siecią wewnętrzną, tzn. każdemu w sieci zapodać po bożemu własny CA i z tego poziomu wygenerować certyfikat

 

Godzinę temu, Poziomecki napisał:

Bardzo dużo firm i organizacji stosuje własne CA i własne certyfikaty do sieci odizolowanych i wewnętrznych. Nie jest to nic złego a bardzo często rozwiązuje to naprawdę bardzo dużo problemów.

 

@Spoofyoczywiście że można, ale trzeba to monitorować moim zdaniem (ważność certów) bo jak "coś" pójdzie nie tak to jest problem i bardzo często jakiemuś kierownictwu które jest nietechniczne nie wytłumaczysz dlaczego wszyscy dostali żółty trójkąt i że to wcale nie jest atak hakjerów. Własne CA na wirtualce i ogarnięcie tego to nie powinno zająć dużo czasu na ustawienie a zwłaszcza że bardzo dużo jest oprogramowań open source, więc koszt wynosi 0zł.

A możecie podzielić się jakiś casestudio, tak by systemy intranetowe i np. webserwisy switchy były po ssl (i nie samo podpisywalnym).

[Spoofy]

2 godziny temu, spex napisał:

 

A możecie podzielić się jakiś casestudio, tak by systemy intranetowe i np. webserwisy switchy były po ssl (i nie samo podpisywalnym).

Generalnie własne CA i delegację w tej filozofii najczęściej można spotkać w dużych internalach lub gov'ach i tutaj nie mogę wymienić duzo krótko literowych skrótów, ale pewno wiesz o co chodzi.

W kwestii non self-signed to również bez podania szczegółów - chodzi np. o serwery LDAP, mail czy inne, gdzie wybrana część ma być dostępna z internala - tak jak wspomniałem, tutaj z powodzeniem wypychałem certa LET np. post-hook'iem certbot'a za pomocą scp po kluczach ssh na docelową maszynę w internalu.

Warto tutaj nadmienić, że często zdradzamy informacje o internalu w przypadku komercyjnego CA czy publicznej strefy DNS wskazującej na wewnętrzne adresy, -zdradzamy informacje o infra w internalu, co może przynieść skutek odwrotny do zamierzonego (certyfikat wygenerowany np. na wazny-tajny-projekt.domena.tld wskazujący na adres z klasy lokalnej etc.), zaś własny DNS w internalu w tym przypadku może mocno ograniczyć używanie takich mechanizmów jak DNSSEC.

Spory temat do rozważań. Chodzi bardziej o "chain of trust" - komu ufamy i dlaczego, a to zależne od konkretnych wymogów i konkretnego case'a. Wracając na ziemię - w przypadku własnego, nie biznesowego NC to sugerowałbym po prostu self-signed i potwierdzenie wyjątku.

[yLuno]

W dniu 8.12.2021 o 18:53, st220 napisał:

Najlepiej przez dns, jest wiele pluginów aby korzystać z publicznych dns jak np. cloudflare czy ovh. Wtedy nie ma znaczenia czy miejsce korzystania nie jest publiczne.

 

Przerabiałem temat w poprzedniej fabryce i CF ma dostęp do DNS przez api dopiero w wersje Enterprise, pakiet free tego nie ma, aws, azure ma płatne hostowanie DNS i chyba tylko w DigitalOcean utrzymanie strefy DNS i dostęp do niej przez api jest za free. W sumie nie wiem jak jest w ovh z DNS i dostępem do niego przez api.

[psz]

3 minuty temu, yLuno napisał:

CF ma dostęp do DNS przez api dopiero w wersje Enterprise, pakiet free tego nie ma

 

Kompletna nieprawda. DNS przez API jest dostępne w każdym planie, nawet darmowym (z małymi wyjątkami). 

[yLuno]

22 minuty temu, psz napisał:

 

Kompletna nieprawda. DNS przez API jest dostępne w każdym planie, nawet darmowym (z małymi wyjątkami). 

 

Było to z dobre 2-3 lata temu i teraz jak sobie chwilę pomyślałem to źle napisałem/wyraziłem się. Ja korzystałem z AWS i tam o ile dobrze pamiętam tworzyłem subdomene w stylu _acme.domena.w.lan.com i tylko przez api był do niej dostęp. Pisząc o CF rzeczywiście źle napisałem, że nie ma dostępu do dns przez api, tylko właśnie chodziło mi o ograniczenie tego dostępu tylko do konkretnej subdomeny przy pomocy której generujemy certy z serwera, który stoi w LAN. Jednak nie upieram się i być może coś się w CF zmieniło pod tym względem.

[psz]

Nic się nie zmieniło. DNS przez API był dostępny "od zawsze".

[yLuno]

1 godzinę temu, psz napisał:

Nic się nie zmieniło. DNS przez API był dostępny "od zawsze".

Tak jak napisałem - chodzi mi o ograniczanie tego dostępu przez api aby nie dawać do całej domeny tylko do konkretnej subdomeny przy pomocy której będziemy generować danego certa. Pamiętam że te kilka lat temu w CF tego nie było w darmowym planie czyli pełen dostęp przez api albo wcale i dopiero w najwyższym pakiecie to było możliwe.

[Spoofy]

16 minut temu, yLuno napisał:

Tak jak napisałem - chodzi mi o ograniczanie tego dostępu przez api aby nie dawać do całej domeny tylko do konkretnej subdomeny przy pomocy której będziemy generować danego certa. Pamiętam że te kilka lat temu w CF tego nie było w darmowym planie czyli pełen dostęp przez api albo wcale i dopiero w najwyższym pakiecie to było możliwe.

W takim przypadku wystarczy zwykłe proxy z restrykcjami dla konkretnych endpoint'ów lub własny, prosty skrypt (np. oparty na którejś ze wspieranych przez CloudFlare'a klas np. https://github.com/cloudflare/cloudflare-php ) filtrujący endpoint'y lub wykonujący tylko wyznaczone akcje, np. przekazując output bezpośrednio z api CF ;)

[Tweedlex]

3 godziny temu, yLuno napisał:

Tak jak napisałem - chodzi mi o ograniczanie tego dostępu przez api aby nie dawać do całej domeny tylko do konkretnej subdomeny przy pomocy której będziemy generować danego certa. Pamiętam że te kilka lat temu w CF tego nie było w darmowym planie czyli pełen dostęp przez api albo wcale i dopiero w najwyższym pakiecie to było możliwe.

To mogłeś używać innego DNS API, acme.sh ma wiele providerów, nawet AWS DNS.

2 godziny temu, Spoofy napisał:

W takim przypadku wystarczy zwykłe proxy z restrykcjami dla konkretnych endpoint'ów lub własny, prosty skrypt (np. oparty na którejś ze wspieranych przez CloudFlare'a klas np. https://github.com/cloudflare/cloudflare-php ) filtrujący endpoint'y lub wykonujący tylko wyznaczone akcje, np. przekazując output bezpośrednio z api CF

On chyba ma na myśli, że do CF nie doda subdomena.domena.tld (jako główna strefa którą zarządza), tylko musi dodać pełną domena.tld, a jego domena.tld używa DNSów AWS'a.

[yLuno]

7 godzin temu, Tweedlex napisał:

To mogłeś używać innego DNS API, acme.sh ma wiele providerów, nawet AWS DNS.

On chyba ma na myśli, że do CF nie doda subdomena.domena.tld (jako główna strefa którą zarządza), tylko musi dodać pełną domena.tld, a jego domena.tld używa DNSów AWS'a.

 

Wiem, że jest dużo różnych dns api w LE/acme. Po prostu CloudFlare ma darmowy DNS - jeżeli się patrzy na koszty. Ja tak jak napisałem, używałem AWS dns api z racji możliwości ograniczenia dostępu tylko do wybranej subdomeny, bo w LAN miałem dużo różnych serwerów typu dev, test, tmp itd. itp. i zostawianie na każdym api z pełnym dostępem do strefy dns to by było klasyczne proszenie się o kłopoty Tak jak ktoś pisał, można zrobić jeden serwer, który generuje certa i potem przez post_hook czy tam zwykłym skryptem przerzucać to gdzieś dalej, tylko to jest fajne jak ma się wszystko pod swoją kontrolą i tego pilnuje.

[psz]

Możesz stworzyć API Token, który będzie miał dostęp np. tylko do rekordów DNS dla jednej strefy DNS.

 

Stworzenie API Tokena, który miałby dostęp tylko do pojedynczego rekordu DNS, teoretycznie jest możliwe, jeśli stworzysz Token poprzez API, ale z tego, co mi wiadomo jest to niesprawdzone i może nie działać. Z tego powodu nie ogłaszamy oficjalnie tej funkcjonalności.

 

Niestety, dodawanie subdomen do konta Cloudflare jest funkcją dostępną dla klientów Enterprise.

 

Proponuję spróbować jednych z poniższych:

•  Dodać rekord CNAME wskazujący z Twojej domeny na specjalną domenę "tylko do weryfikacji" i dać dostęp przez API tylko do niej, np.

  _acme-challenge.example.com CNAME example.com.acme-challenge.net

  Niektóre klienty Let's Encrypt umożliwiają takie przekierowanie. Alternatywnie napisać prosty skrypt, który by dodawał/usuwał rekordy DNS i podpiąć go jako hook do klienta Let's Encrypt.

• To samo, co powyżej, ale CNAME wskazujący na innego providera, w którym taki ograniczony dostęp przez API jest możliwy. Lista pluginów DNS dla Certbot'a.

• Stworzyć prosty Worker, na którego wskazałbyś swojego klienta Let's Encrypt, w tym skrypcie ukryłbyś API Token, i odrzucał requesty, które próbowałby modyfikować rekordy DNS inne niż _acme-challenge.