Skocz do zawartości
  • Cześć!

    Witaj na forum RootNode - aby pisać u nas musisz się zarejestrować, a następnie zalogować. Posty pisane z kont niezarejestrowanych nie są widoczne publicznie.

Certyfikat Letsencrypt wewnątrz sieci firmowej


Kaziu

Rekomendowane odpowiedzi

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?

Odnośnik do komentarza
Udostępnij na innych stronach

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.

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

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 przez kix
  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

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.

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

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.

  • Lubię 1
  • Super! 1
Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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ść.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

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).

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 4 miesiące temu...
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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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 ;)

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

 

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.