Update #1
Sikerült Let's Encrypt tanúsítványt generálni a belső szerverhez. (Volt küzdés...) Beállítottam a Postfix és Dovecot pároshoz.
Ezzel most úgy tűnik, hogy jó lett.
Az érdekesség az, hogy a Let's Encrypt tanúsítványnál is feldobta a Thunderbird a Biztonsági kivétel hozzáadása ablakot (Ismeretlen identitás)!
Viszont most, hogy hozzáadtam a kivételekhez, nem dobta fel többet a kivétel hozzáadását!
Többszöri gép újraindítás után sem. (Remélem még holnap is így lesz...)
Akkor ez a Let's Encrypt tanúsítvány sem elfogadott a levelező szervereknél?
Esetleg nekem nem sikerült jó tanúsítvány generálni?
Sziasztok!
Adott egy Relay Mail szerver, belső hálózaton (Ubuntu 18 LTS, Postfix, Dovecot) amely lehúzza a szolgáltatótól a leveleket, illetve küldi a szolgáltató felé az üzeneteket.
A szerver 2019-ben lett Ubuntu 18 LTS -re frissítve (előtte Ubuntu 16 volt). Akkor volt némi küzdés vele, mivel a régi WEB Mail nem működött a 18-as alatt, illetve a levelezés sem ment rendesen. WEB Mail -ből a RoundCube lett feltéve és sikerült a levelező szervert is jól beállítani. Azóta tökéletesen működött.
Most hétfő óta a Thunderbird-ben állandóan megjelenik a "Biztonsági kivétel hozzáadása" ablak és hiába van a "Kivétel megőrzése" bekapcsolva a következő indításnál újra megjelenik, jobb esetben, rosszabb esetben nem jelenik meg csak "köröz a homokóra" és nem húzza le a leveleket a szerverről.
Biztonsági kivétel hozzáadása
Ismeretlen identitás
A tanúsítvány nem megbízható, mert nem ellenőrizte kibocsátóként egy biztonságos aláírást használó elismert hatóság
Első körben meg gyanúsítottam a Thunderbird-öt. Reinstall, de ugyan az a hiba. Feltettem belőle régebbi verziókat amivel jól üzemet de azoknál is ugyan ez a hiba áll fent.
Ránéztem a szerveren a "saját készítésű" tanúsítványokra, mind a kettő 2024-ig jó. Gondoltam mivel arra panaszkodik generálok egy új tanúsítványt. Megküzdöttem vele, ebben a tanúsítványban már a szerver neve is szerepelt. Be is másoltam a tanúsítványokat de nem lett jobb, ugyan az a hiba. (A Thunderbird az új tanúsítványt találta már meg amiben a szerver neve is szerepelt.)
Gondoltam tesztelésnek generálok egy Let's Encrypt tanúsítványt a mail szerverhez. (A saját WEB szerverhez sikerült már generálni vele tanúsítványt, az működik is.)
Első körben belefutottam abba, hogy csak külső interneten lévő szervernek lehet tanúsítványt generálni. Mivel a szerver belső hálózaton van így nem sikerült.
Találtam egy útmutatót ilyen esetre. Szerencsére a saját WEB-es tárhelyem konfigurálható a CPanel-en keresztül. Ebben felvettem egy új aldomaint, belsoszervernev.sajatdomain.hu néven és a belső szerver IP címét adtam meg (192.168.2.xx, A típus).
sudo certbot certonly --standalone -d belsoszervernev.sajatdomain.hu
Ekkor arra panaszkodott hogy "Problem binding to port 80: Could not bind to IPv4 or IPv6."
Néztem, nyitva van az a port és ott is a WEB szerver, miért nem találja !?!
Néhány kör futása után kiderült, hogy a certbot akarja használni a 80 portot. Letiltottam a WEB szervert és újabb hibára futott.
Failed authorization procedure. belsoszervernev.sajatdomain.hu (http-01): urn:ietf:params:acme:error:dns :: no valid A records found for belsoszervernev.sajatdomain.hu; no valid AAAA records found for belsoszervernev.sajatdomain.hu
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: belsoszervernev.sajatdomain.hu
Type: None
Detail: no valid A records found for belsoszervernev.sajatdomain.hu; no
valid AAAA records found for belsoszervernev.sajatdomain.hu
Nos itt hagytam abba és kezdtem el "fonogatni" a kötelet.
Valakinek van ötlete arra, hogy lehetne javítani, hogy a Thunderbird ne dobja fel a "Biztonsági kivétel hozzáadása" ablakot?
Köszönöm.
- 401 megtekintés
Hozzászólások
mi belső domainekhez dns challenget használunk certbottal, akkor csak a dns-t kell tudni módosítani.
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
- A hozzászóláshoz be kell jelentkezni
Most jön a nagy kérdés: van-e valami kész szoftver házi CA üzemeltetéséhez? (Mármint nyers OpenSSL parancsokkal (nyilván scriptekkel) is meg lehet csinálni, ha értünk hozzá, de azt se felejtsük el, hogy évente minden szervernek új cert-et kell generálni, még akkor is, amikor ez már nem érdekes újdonság csak plusz egy ismétlődő meló.)
- A hozzászóláshoz be kell jelentkezni
Ez a "házi CA" a Certificate automatikus generálása lenne? Vagy mire gondolsz?
Amúgy a gond az, hogy nem is évente hanem három havonta jár le a tanúsítvány. Legalábbis ha jól olvastam.
Tényleg az az érdekes, hogy több éven keresztül nem volt ezzel semmi probléma. Használta a saját tanúsítványát a Ubuntu szerverről.
Most hétfőtől viszont nem megy! Mint írtam a tanúsítvány 2024-ben jár le, ez nem lehet a gond.
Több gépről, virtuális gépről próbáltam de mindig feldobja a Thunderbird a Biztonsági kivétel hozzáadása ablakot.
Ami érdekes, hogy a WEB-Mail (roundcube), gond nélkül megy, csak a Thunderbird fut hibára!
(Vásárolni kellene egy tanúsítványt egy belső szerverhez?!? Nem is a pénz miatt, de mivel nincs interneten a gép, szerintem nem is tudnának hozzá tanúsítványt adni. Hasonlóan, mint a Let's Encrypt tanúsítványnál...)
- A hozzászóláshoz be kell jelentkezni
Nem pénz kell hozzá, hanem idő/tanulás/munka. Amikor ilyesmivel foglalkoztam, ebből indultam ki:
https://jamielinux.com/docs/openssl-certificate-authority/index.html
- A hozzászóláshoz be kell jelentkezni
de mivel nincs interneten a gép, szerintem nem is tudnának hozzá tanúsítványt adni. Hasonlóan, mint a Let's Encrypt tanúsítványnál...
Tudnak. Ha a parent domain a tied, "hivatalosan is", akkor bármilyen hostnévre kapsz tanúsítványt alatta, bármelyik publikus CA-tól. Sehol nincs előírva, hogy a CA-nak látnia kell tudni a kiállított hostnév mögötti szervert (vagy akár csak benne kell legyen a publikus dns-edben).
Sőt, a Let's Encrypt is tud ilyet, ehhez csak annyi kell, hogy ne http-alapon menjen az ellenőrzés, mert ahhoz tényleg el kéne tudja érni az Interneten keresztül azt a hostnevet, hanem dns-alapon (ilyenkor azt ellenőrzik, hogy a dns-be be tudsz-e írni egy általuk adott challenge-et - ha igen, akkor jogosult vagy az adott hostnévre tanúsítványt kérni), ehhez persze a dns adatbázisodat kell tudnod editálni, leginkább scriptből (különben masszívan kényelmetlen lesz a dolog).
- A hozzászóláshoz be kell jelentkezni
Nekem is úgy sikerült Let's Encrypt tanúsítvány generálni, hogy a saját WEB-helyen felvettem a DNS-be a szervereket aldomain-be a saját IP címükkel, majd egy txt rekordot adtam hozzá és abba került a Let's Encrypt ellenőrző kód...
>>(különben masszívan kényelmetlen lesz a dolog).
Ja-ja, nem igazán szeretnék három havonta manuálisan tanúsítványokat generálni. Ezért is próbálok rájönni, hogy hétfőtől miért nem fogadják el az Ubuntu saját tanúsítványát.
- A hozzászóláshoz be kell jelentkezni
Csak egy kóbor gondolat: lehet, hogy a Thubdebird saját CA-kat hoz és ott az ellenőrzéshez használatos CA nem került frissítésre, így az érvénytelen és így az ezzel ellenőrizendő tanúsítványok is azok?
- A hozzászóláshoz be kell jelentkezni
Igen, én is gondoltam arra, hogy valamiért a Thunderbird nem jó tanúsítványt használ.
Töröltem is a Thunderbirdből a mail szerverhez tartozó tanúsítványokat, így újra kellett felvennie.
Ezután ellenőriztem is, (tanúsítvány megtekintés) ténylegesen a mail szerverhez tartozó tanúsítványt húzta le.
Sajnos ezután sem lett jó, ugyan az volt a hiba.
Azt nem értem, hogy mi változott hétfőn, hogy az Ubuntu saját tanúsítványát nem fogadja el a levelező?
Ha jól emlékszem Ubuntu 8 LTS-el kezdtek ezek a szerverek még 2008-ban. Volt párszor csere új gépekre, ill. migrálás az akkori "új" Ubuntura. Soha nem volt gond az Ubuntu saját tanúsítványával...
Az más kérdés, hogy a mail küldésnél a szolgáltató tanúsítványával milyen "jókat" lehetett szenvedni. (terminál, ssl, bejelentkezni, ott megjelenik a cert, txt-be kimásolni, készíteni belőle egy tanúsítványt, tesztelni, behúzni a postfix alá...)
- A hozzászóláshoz be kell jelentkezni
Az milyen, hogy "az Ubuntu saját tanúsítványa"?
- A hozzászóláshoz be kell jelentkezni
Bubis repóból érkező ca-certificates.ficemfacom-verzio.deb csomagra tippelek:-D
Egyébként áttételesen én is belefutottam, hogy a buguntu-s ca-certs csomag nem tartalmazta (nem tartalmazza?) a LE "új" tanusítványláncához tartozó CA-kat megbízhatóként - ezt érdemes megnézni, mert lehet, hogy az op.-nek ez a gondja.
- A hozzászóláshoz be kell jelentkezni
>> .ficemfacom-
:D
Zseniális...
(Már ezért megérte egy hétig szenvedni... :))
- A hozzászóláshoz be kell jelentkezni
Tanúsítvány
Általános név
ubuntu
Kibocsátó neve
Általános név
ubuntu
Érvényesség
Kezdete
Tue, 03 Dec 2019 22:14:50 GMT
Vége
Fri, 30 Nov 2029 22:14:50 GMT
Nyilvános kulcs információ
Algoritmus
RSA
Kulcsméret
2048
Kitevő
65537
Modulus
D8:57:E2:78:C7....................
Egyebek
Sorozatszám
4A:FC:2E:80:E6...................
Aláírási algoritmus
SHA-256 with RSA Encryption
Verzió
3
Letöltés
PEM (tanúsítvány)PEM (lánc)
Ujjlenyomatok
SHA-256
D9:E6:0E:81:CA...................
SHA-1
F2:59:30:85:8B............
- A hozzászóláshoz be kell jelentkezni
Ez egy self-signed cert, ami azt tanusítja, hogy... Szóval semmit sem. (Bárki tud self signed-et gyártani ugyenerre a CN-re, azaz semmilyen szinten nem lehet benne megbízni, hogy ez az, amit _te_ csináltál.)
- A hozzászóláshoz be kell jelentkezni
10+ éve ezzel (vagy hasonlóval) működött gond nélkül. Mint írtam, ezek belső hálózatokon lévő szerverek...
- A hozzászóláshoz be kell jelentkezni
20+ éve meg a telnet és az ftp is elfogadható volt... Csinálj belső CA-t, azzal írj alá egy *.belso.domain wildcard certet (CN, és SAN DNS1 is, a felhasználást kizárólag webszerverek azonosítására korlátozva), szórd szét minden gépre, ahol használni akarsz belül tanusítványt, _és_ gondoskodj arról, hogy a belső CA-d publikus kulcsa minden benti gépre odakerüljön megbízható legfelső szintű kiadóként.
- A hozzászóláshoz be kell jelentkezni