search

nav-gov-hu / Online-Invoice

Public repository of the Online Invoice System
Other
139 stars 52 forks source link

api.onlineszamla.nav.gov.hu cert le fog járni #1027

Open EPluribusUnum opened 1 year ago

EPluribusUnum commented 1 year ago

@NTCA-developer , @NTCA-supporter , @NTCA-tax Az api.onlineszamla.nav.gov.hu cert-je nem lett meghosszabbítva, az még mindig 2023.01.07-ig érvényes csak.

(onlineszamla.nav.gov.hu és nav.gov.hu az már 2024.01.13-ig érvényes)

tsamu commented 1 year ago

Nem volt 3x belerakva, csak a hibákat dobálta 3x, a cert maga jó. 0 depth-et látott a debian a láncban, ezért nem tudott végigmenni a láncon magától az api szerver hibás beállítása miatt.

depth=0 ...
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 ...
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0..
verify return:1

Beállították rendesen, most jó. A vita-kérdés kb arról szól így a végére ahogy én látom, hogy a gép-gép kapcsolatot ki hogyan értelmezi és manuálisan bemásolt enduser cert nélkül végig tudjon-e a GÉP menni egy cert láncon vagy sem. Szerintem nem is kérdés, hogy végig kellene menni gond nélkül (korábban ment is).

amargo commented 1 year ago

Nem volt 3x belerakva, csak a hibákat dobálta 3x. 0 depth-et látott a debian a láncban, ezért nem tudott végigmenni a láncon magától az api szerver hibás beállítása miatt.

depth=0 ...
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 ...
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0..
verify return:1

Beállították rendesen, most jó. A vita-kérdés kb arról szól így a végére ahogy én látom, hogy a gép-gép kapcsolatot ki hogyan értelmezi és manuálisan bemásolt enduser cert nélkül végig tudjunk-e menni egy cert láncon vagy sem. Szerintem nem is kérdés, hogy végig kellene menni gond nélkül.

Valóban csak 1x volt benne (hibásan) a szerver cert, jogos! Nem láttam a régi lácont :( de szinte biztos hibás volt az intermediate (azaz maga a cert, de erre pl böngészők nem annyira érzékenyek).

tsamu commented 1 year ago

de szinte biztos hibás volt az intermediate.

odáig el sem jutott a folyamat, rögtön elakadt az elején, mivel a teljes lánc leküldése hiányzott, a Certificate chain részével semmi gond nem volt

Certificate chain
 0 s:C = HU, L = Budapest, O = Nemzeti Ad\C3\B3- \C3\A9s V\C3\A1mhivatal, CN = *.onlineszamla.nav.gov.hu, serialNumber = 1.3.6.1.4.1.21528.2.3.2.7168
   i:C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = info@e-szigno.hu
  1. Client Hello
  2. Server Hello Along with the Server Hello, the server will also send the certificate[3] of the server with the certificate chain. The certificate chain will be validated against the certificates in the client trust store[4].
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (OUT), TLS alert, unknown CA (560):
amargo commented 1 year ago

odáig el sem jutott a folyamat, rögtön elakadt az elején, mivel a teljes lánc leküldése hiányzott, a cert chainel semmi gond nem volt

A láncba tartozik az intermediate is, ha chain-el nem volt semmi gond, akkor ezt miért kaptad? verify error:num=21:unable to verify the first certificate Meg van még a "hibás" cert dump-ja? Kíváncsi vagyok mit nem értek megfelelően :)

Én az itteni commentek alapján csak ezt látom: https://github.com/nav-gov-hu/Online-Invoice/issues/1027#issuecomment-1373431019 Ebben pedig látszólag nincs ott csak 1db cert-et tartalmaz (egy másik commentben is ilyet láttam).

neszt commented 1 year ago

@NTCA-supporter bevallom meg lettem tévesztve, hogy le KELL tölteni a tanúsítványt ahhoz, hogy a NAV apiját használni tudjuk. Most, hogy ki lett javítva a tanúsítványlánc a szerver konfigurációjában, örömmel látom, hogy nem kell semmilyen tanúsítvánnyal foglalkozni, az operációs rendszerek gond nélkül tudnak csatlakozni a https apihoz. Ha ez tervezetten így van, akkor kicsit furcsállom, hogy ezt nem kommunikáltátok egyértelműen.

Miért lehet letölteni a tanúsítványt, egyáltalán kinek lehet rá szüksége?

neszt commented 1 year ago

@NTCA-supporter bevallom meg lettem tévesztve, hogy le KELL tölteni a tanúsítványt ahhoz, hogy a NAV apiját használni tudjuk. Most, hogy ki lett javítva a tanúsítványlánc a szerver konfigurációjában, örömmel látom, hogy nem kell semmilyen tanúsítvánnyal foglalkozni, az operációs rendszerek gond nélkül tudnak csatlakozni a https apihoz. Ha ez tervezetten így van, akkor kicsit furcsállom, hogy ezt nem kommunikáltátok egyértelműen.

Miért lehet letölteni a tanúsítványt, egyáltalán kinek lehet rá szüksége?

@NTCA-developer , @NTCA-supporter , @NTCA-tax , @renced42

renced42 commented 1 year ago

Üdv mindenkinek!

A témában visszatértem és utána jártam a kérdésnek, hogy pontos választ tudjak adni.

A kérdésre, hogy miért kell letölteni a tanúsítványt annak sok oka lehet, hosszú évek tapasztalata mondatja ezt. De nyilván változnak az idők a technikák, tehát nem feltétlen kötelező vagy kell.

A tanúsítvány lánc probléma: Normál esetben a tanúsítványláncot is küldjük. Az új tanúsítvány esetében viszont a probléma az volt, hogy a lecserélt tanúsítványt korábban más állította ki, így a korábban működő láncba nem illeszkedett az új tanúsítvány, ergo nem küldte a szerver a láncot. Ezért jött ez a hibaüzenet valóban. A lánc helyes beállítása a problémát megoldotta. Mivel a korábbi cseréknél nem kellett ezzel bajlódni, mert már be volt konfigolva, ezért volt furcsa a hibajelenség, hiszen semmit sem kellett eddig sem állítani.

Tehát ilyen szempontból nálunk volt a probléma ami miatt a hiba jött.

Ahol egyébként a szükséges tanúsítványok le vannak töltve és be vannak konfigurálva ott ez a hiba nem jelentkezett. Tehát ez is egy ok lehet arra, hogy letöltésre kerüljenek szükség esetén a tanúsítványok.

slaci commented 1 year ago

@renced42 az utolsó bekezdésed nem teljesen igaz, ha kicsit visszaolvasol. A problémát az eszkalálta, hogy a letöltött tanúsítvánnyal csak valami olyan együttállással ment, ami ugye nem derült ki, hogy mi volt pontosan. Kicsit ismételve önmagam debian 11en és ubuntu 22.04-en megoldotta a problémát a tanúsítvány letöltése és curlnak megadása, a régebbi debianokon pedig semmit nem számított, nem működött. Nekünk pl egy régebbi debianon ment a progi ami hívogatta és azon sehogy sem ment.

Én bevallom csak curl-al próbáltam, mert a mi progink azzal tolja, de állítólag a wget kevésbé volt allergiás a rossz certre (ezt én magam nem próbáltam).

Miután megjavult a cert, utána egyből automatán jó lett a régebbi cuccokon is, letöltögetés nélkül.

Curl esetén könnyen ki lehet kapcsolni az ssl veryfit és beindul ilyenkor, de az bátor dolog. Amíg a fejlesztők nem erősítik meg, hogy rossz a cert, addig simán lehetne az is, hogy felnyomták a szervert és a verify kikapcsolásával jöhetnek az ebből adódó gondok. Elvileg a jó megoldás ilyen helyezetekre ha újrapróbálhatóak azok a kérések, amik kapcsolódási problémából adódtak.