api.onlineszamla.nav.gov.hu cert le fog járni about online-invoice HOT 58 OPEN

Rosszul van beállítva a szerver, az e-szingó ellenőrzője szépen ki is írja: https://srv.e-szigno.hu/microsecssl&hosturl=api-test.onlineszamla.nav.gov.hu

A teljes tanúsítvány lánc leküldése a kliensnek NINCS beállítva

Hiba leírása
A megadott webszerver SSL beállításai NEM megfelelőek.

Kliens oldalon nem lehet az e-Szignó Hitelesítés Szolgáltató megbízható főtanúsítványáig felépíteni a tanúsítási láncot! A webszerver konfigurációjában nem került beállításra a teljes tanúsítvány lánc leküldése a kliens felé.

from online-invoice.

@NTCA-supporter , a jövőben jó lenne ha nem 2 napos ablak lenne, hanem legalább 14 nap, de még jobb lenne a 31. (2 éjszaka esik a cert frissítés és a lejárat közé csak). Abban az ablakban kell az összes ügyfelünknek újraindítani a JVM-et a cert frissítés miatt.

from online-invoice.

Akkor most már az is látjuk, hogy miért célszerű nem az utolsó pillanatban lecserélni a certet, avagy QeD.

from online-invoice.

Javították, most már nem dob hibát... :)
https://srv.e-szigno.hu/microsecssl&hosturl=api-test.onlineszamla.nav.gov.hu

from online-invoice.

Tanúsítvány frissítés minden évben lesz.

Expires On Monday, 22 January 2024 at 15:11:46

Találkozunk 2024. január 22-én.

from online-invoice.

Boldog Új Esztendőt mindenkinek!

@renced42 leírom, hogy nálunk (fejlesztői oldalon) ez hogy csapódott le, hogy lássátok miért is kevés a néhány nap, sőt, ilyenkor évfordulókor még az 1-2 hét is. (Minket csak a gép-gép kapcsolat tanúsítványa érint.)

Dec. 20-án 15:44kor kaptam a Tajekoztato.NoReply nav címről egy levelet, hogy le fog járni a tanúsítvány 2022. december 31-én.
Nem tudom, hogy mikor és hol iratkoztam fel erre, de nem is érdekes, tök jó, hogy jött a levél. Jó néhány ügyfelünk is megkapta, mert elkezdtek mozgolódni, hogy mi a teendőjük. Gyorsan segítsünk nekik, mert mindenki szabira fog menni, az ügyvitel, az IT oldaláról is, nehéz lesz a kommunikáció az ünnepek alatt.

El is készítettük a kommunikációs levelet, hogy mit kell tenniük, de mi magunk hiába csináltuk végig a leírásunkat, nem frissült a tanúsítvány az apinál (nálunk nem kézi letöltés és installálás van, mert az ügyfélkör egy részének ez komoly kihívás okozott, így megcsináltuk az automata frissítést, így, aki azt sem tudja mi az a tanúsítvány címtár, annak van saját megoldásunk). Ok, láttuk, hogy nem december 30-énm hanem január 7-én jár le, elengedtük a kérdést, elkezdődtek a szabadságolások, tudtuk, hogy van még kis időnk, a két ünnep közt majd ránéz az ügyelet, ha frissül, küldjük a tájékoztatást, minden ok lesz. Ezt kommunikáltuk az ügyfelek felé is.

De nem frissült, egészen tegnapig, és erről egyébként nem jött levél a Tajekoztato.NoReply-ról, hogy bocs, 01.05. 17:00 után próbálja mindenki, mert akkortól lesz ok a gép-gép dolog. Az ügyfél nem érti, hogy mi mit bénázunk, kapott egy levelet, hogy már 12.13-án megújított a nav valamit, mi miért mondjuk, hogy még nem ok a dolog.

Nagyon rossz ez az év végi időpont, de az év eleji is. Sok cég ilyenkor leáll, áll a termelés, áll az ügyvitel, de mondjuk megy egy webshop, ami számláz. Az ügyvitellel foglalkozó IT azonban nagyon alapjáraton van, ők is kötelező szabin vannak, nagyon fontos lenne, hogy ne két nap álljon rendelkezésre egy ilyen frissítésre, és, ha kimegy a kommunikációs levél róla, akkor tényleg lehessen frissíteni. Elsőre. Jól.

Köszönöm!

from online-invoice.

A jövőben a hibákat elkerülendő a teszt és az éles certjét nem egyszerre kéne cserélni és akkor napvilágra bukna az összes "hibás" értelmezés (mint ahogy nálunk sem működött, ki kellett kapcsolni a klienseken a host/peer verify-t a javításotokig).

Egy lehetséges scenario:

• kikerül a tesztre a lejárat előtt x nappal
• mindeki megnézi, hogy a saját vackával működni fog-e az új cert, adott beállítással stb
• így van idő a problémákat, sajátságos értelmezéseket kikalapálni
• kikerül az élesre az új cert a lejárat előtt x nappal

Ettől függetlenül én azért csak az e-szigno ellenőrzőjének hiszek. Ha ott azt mondják, hogy nem volt jó a korábbi beállítás akkor az bizony nem volt jó. Láttunk már arra példát, hogy valami véletlenül pont működött. Most végigfut és láss csodát működik is mindenhol minden.

from online-invoice.

@renced42 , az előző tanúsítványon biztos hogy még be volt kapcsolva a komplett lánc publikálása. Az auto import logunkban benne van hogy a teljes láncot feldolgoztuk és beimportáltuk a cacerts-be.

[INFO] 2022.12.25 10:49:32,873 - "main" - Certificates for api.onlineszamla.nav.gov.hu:443 imported to /u0/nav_eles_50/jre1.8.0_333/lib/security/cacerts
Alias : .onlineszamla.nav.gov.hu
Subject CN=.onlineszamla.nav.gov.hu, O=Nemzeti Adó- és Vámhivatal, L=Budapest, C=HU
Issuer CN=NetLock Expressz (Class C) Tanúsítványkiadó, OU=Tanúsítványkiadók (Certification Services), O=NetLock Kft., L=Budapest, C=HU
sha1 63645CB7305605D2F4E286C03FA179DAFE3691F6
md5 A9E4B0193502EC2A2EA005199BBC3799
Alias : NetLock Expressz (Class C) Tanúsítványkiadó
Subject CN=NetLock Expressz (Class C) Tanúsítványkiadó, OU=Tanúsítványkiadók (Certification Services), O=NetLock Kft., L=Budapest, C=HU
Issuer CN=NetLock Arany (Class Gold) Főtanúsítvány, OU=Tanúsítványkiadók (Certification Services), O=NetLock Kft., L=Budapest, C=HU
sha1 3F6F589F5A28466AE295D5E18EBD139C57C68DB5
md5 728548DBD378D1409855D3D824AD8CEE
Alias : NetLock Arany (Class Gold) Főtanúsítvány
Subject CN=NetLock Arany (Class Gold) Főtanúsítvány, OU=Tanúsítványkiadók (Certification Services), O=NetLock Kft., L=Budapest, C=HU
Issuer CN=NetLock Arany (Class Gold) Főtanúsítvány, OU=Tanúsítványkiadók (Certification Services), O=NetLock Kft., L=Budapest, C=HU
sha1 06083F593F15A104A069A46BA903D006B7970991
md5 C5A1B7FF73DDD6D7343218DFFC3CAD88

from online-invoice.

Debian alatt eddig jó volt, most ezt dobja:

curl -v https://api.onlineszamla.nav.gov.hu

• Trying 84.206.52.73:443...
• Connected to api.onlineszamla.nav.gov.hu (84.206.52.73) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• 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):
• SSL certificate problem: unable to get local issuer certificate
• Closing connection 0
  curl: (60) SSL certificate problem: unable to get local issuer certificate

wget https://api.onlineszamla.nav.gov.hu
--2023-01-06 00:12:53-- https://api.onlineszamla.nav.gov.hu/
Resolving api.onlineszamla.nav.gov.hu (api.onlineszamla.nav.gov.hu)... 84.206.52.73
Connecting to api.onlineszamla.nav.gov.hu (api.onlineszamla.nav.gov.hu)|84.206.52.73|:443... connected.
ERROR: The certificate of ‘api.onlineszamla.nav.gov.hu’ is not trusted.
ERROR: The certificate of ‘api.onlineszamla.nav.gov.hu’ doesn't have a known issuer.

from online-invoice.

Sziasztok

Mi több szervert üzemeltetünk, így készítettünk scriptet a probléma javítására. Alább részletezem, ha érdekel valakit.

CentOS-en kicsit körülményesebb a megoldás, több certifikáció letöltése szükséges, szám szerint 4:
https://onlineszamla.nav.gov.hu/api/files/container/download/certificate_20230105.zip
http://www.e-szigno.hu/rootca2009.crt
http://www.e-szigno.hu/rootca2017.crt

És az utolsó amit én nem tudtam másképp beszerezni:
https://srv.e-szigno.hu/index.php&cms=on?lap=tanusitvanytar
Itt beírod, hogy *.onlineszamla.nav.gov.hu

És a kibocsátó mezőnél az e-Szigno SSL CA 2014 linkkel tudod letölteni a 4-ik certifiációt.

Mi Centos 6-on és 7-en az alábbi scriptet írtuk:

#!/bin/bash
cd /etc/pki/ca-trust/source/anchors
#Certifikációk beszerzése, itt a saját FTP szerverünket használtuk a fentebb írt okok miatt
chmod 644 ./_.onlineszamla.nav.gov.hu_SSL_szerver.cer
chmod 644 ./e-Szigno_SSL_CA_2014.cer
chmod 644 ./rootca2009.crt
chmod 644 ./rootca2017.crt
update-ca-trust enable
update-ca-trust extract
curl -vi https://api-test.onlineszamla.nav.gov.hu/invoiceService/v3/tokenExchange

Debian-on:

#!/bin/bash
mkdir /root/cer-install
cd /root/cer-install
wget https://onlineszamla.nav.gov.hu/api/files/container/download/certificate_20230105.zip
unzip certificate_20230105.zip
mv _.onlineszamla.nav.gov.hu_SSL_szerver.cer /usr/local/share/ca-certificates/api_onlineszamla_nav_gov_hu.crt
update-ca-certificates –fresh
rm -fr /root/cer-install
curl -vi https://api-test.onlineszamla.nav.gov.hu/invoiceService/v3/tokenExchange

Remélem tudtam segíteni.

from online-invoice.

Javították, most már nem dob hibát... :) https://srv.e-szigno.hu/microsecssl&hosturl=api-test.onlineszamla.nav.gov.hu

Magyarán megint jobb lett volna nem csinálni semmit és várni, amíg magától megoldódik a probléma 😵‍💫

from online-invoice.

There was no news if you are reading the page in english. :(

from online-invoice.

@NTCA-supporter , a jövőben jó lenne ha nem 2 napos ablak lenne, hanem legalább 14 nap, de még jobb lenne a 31. (2 éjszaka esik a cert frissítés és a lejárat közé csak). Abban az ablakban kell az összes ügyfelünknek újraindítani a JVM-et a cert frissítés miatt.

Kedves @EPluribusUnum A tanúsítványokat amikor megkapta a NAV kihelyeztük még karácsony előtt, ez elég szerencsétlen időpont, de értjük a kérést, próbálunk majd ezen javítani.

Kedves Kollégák röviden reagálnék, tőmondatokban (lehet nem leszek népszerű)!

Kérem, hogy ne a NAV-ot ekézzétek azért, mert a különböző programok és operációs rendszerek különböző módon értelmezik és implementálják a tanúsítványkezelési szabványokat. A kiadott tanúsítványnak semmi baja nincs a világon.

Az hogy összekeveri valaki a böngésző működését egy gépi interfész működésével -> no komment!

Amit tapasztaltunk: A program, vagy az operációs rendszer kulcstárából (nem file szinten), hiányzik a CA vagy lejárt. Ezért a lánc minden tagját oda importálni kell. Az onlineszámla.nav.gov.hu és a api.onlineszamla.nav.gov.hu külön tanúsítvánnyal rendelkezik, a kettőnek nincs köze egymáshoz, Ergo az issuer nem biztos, hogy ugyan az.

A fent leírt hibának jelzett opció eddig sem volt beállítva, de most megkértük a kollégákat nézzék meg, most beállították. Reméljük akkor legközelebb már nem lesz ilyen :)

Tanúsítvány frissítés minden évben lesz.

Nem kell minden nap megnyitni és elolvasni a portál tartalmat. Fel lehet az RSS feedre iratkozni (Portál jobb felső sarka ikon). Az jelzi, ha van új hír, bár nem a leg komfortosabban, de jelzi.

Köszi!

@renced42 Akkor kérlek magyarázd el, hogy ha eddig sem volt beállítva az api webszerverren a hibának jelzett opció és a korábbi end user cert nem szerepelt a ca-certek között, akkor azon miért ment végig a handshake, az új cert esetén pedig miért nem. Tényleg érdekelne.

from online-invoice.

@renced42

Kérem, hogy ne a NAV-ot ekézzétek azért, mert a különböző programok és operációs rendszerek különböző módon értelmezik és implementálják a tanúsítványkezelési szabványokat. A kiadott tanúsítványnak semmi baja nincs a világon.

Az e-szignó szerver ellenőrzője is mutatta a tanúsítvány lánc problémát, nem csak mi operációs rendszereink.

A fent leírt hibának jelzett opció eddig sem volt beállítva, de most megkértük a kollégákat nézzék meg, most beállították. Reméljük akkor legközelebb már nem lesz ilyen :)

Korábban biztosan jó volt a tanúsítványlánc szerver oldalon, tehát ez nem most lett jól beállíŧva.

Annyi történt, hogy most péntek délelőtt rosszul állt.

Szuper, hogy javítottátok!

from online-invoice.

openssl s_client -showcerts -connect api.onlineszamla.nav.gov.hu:443

Azért mert rossz (volt) ez chain (lánc), itt pl lehet olvasni róla: https://sectigostore.com/blog/what-is-an-ssl-certificate-chain-how-does-it-work/

Látható, hogy 3x belerakták a chain-be a szerver cert-et, az intermediate teljesen hiányzott..

Most már a helyes jön vissza:

depth=2 C = HU, L = Budapest, O = Microsec Ltd., CN = Microsec e-Szigno Root CA 2009, emailAddress = [email protected]
verify return:1
depth=1 C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = [email protected]
verify return:1
depth=0 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
verify return:1

from online-invoice.

Szia @EPluribusUnum !
A főoldalról (https://onlineszamla.nav.gov.hu/home):

2023. január 5-én 17 órakor megújul az Online Számla éles és tesztrendszerében használt gép-gép interfészkapcsolat titkosító SSL-tanúsítványa. Az új tanúsítvány a Technikai információk/DokumentációkA linkre kattintva a tartalom új oldalon jelenik meg. menüpontban érhető el és tölthető le tömörített formában.

Üdv

from online-invoice.

@tsamu

Tegnap ugyanezzel szívtam.

A megoldás a következő volt Debian (bullseye) esetén:

wget https://onlineszamla.nav.gov.hu/api/files/container/download/certificate_20230105.zip
unzip certificate_20230105.zip
mv _.onlineszamla.nav.gov.hu_SSL_szerver.cer /usr/local/share/ca-certificates/api_onlineszamla_nav_gov_hu.crt
update-ca-certificates --fresh

Az áthelyezéskor az átnevezés szándékos, a zip-ben lévő fájlnéven nálam az update-ca-certificates --fresh nem foglalkozott vele.

from online-invoice.

Ez most tényleg komoly, hogy így kell mókolni a certificate-al és most egy ország görcsöl azon, hogy megfeleljen a törvényi előírásoknak, mert a NAV nem képes egy normális certificate-et kiadni, ami működik is?????

Nem kizárt, hogy mivel nem vagyok még érintett ebben a témában, valami felett elsiklottam, de valahogy koncepcionálisan nem igazán látom, hogy ennek így kellene működnie.

from online-invoice.

@pongraczi nincs semmi gond az új cert-tel. A standartd szerint 13 hónap a cert maximális élettartama, évente megújítás lesz.

(Lehet a cert frissítést automatizálni is, de a standard szerint ez nem ajánlott, mert alternatív csatornán illik a cert-et beszerezni és frissíteni. Mi automatizáltuk ennek ellenére, mert a felhasználói oldalon nincs meg a megfelelően képzett ember alapanyag. Nálunk az auto frissítés után csak egy szolgáltatás restart kell, arra még képesek az emberek. Elvileg megoldható lenne hogy még restart se kelljen, de saját TrustManager kellene ahhoz, ami a felolvassa a friss cacerts-et)

(Hardcore módban nyílván egyszerűen figyelmen kívül is lehet hagyni a cert problémákat)

from online-invoice.

Ubuntu alatt:

Megnézzük, tényleg gond-e:

pongraczi@tensorpc:~/tmp$ wget https://api.onlineszamla.nav.gov.hu
--2023-01-06 09:40:52--  https://api.onlineszamla.nav.gov.hu/
api.onlineszamla.nav.gov.hu (api.onlineszamla.nav.gov.hu) feloldása… 84.206.52.73
Csatlakozás a következőhöz: api.onlineszamla.nav.gov.hu (api.onlineszamla.nav.gov.hu)[84.206.52.73]:443… kapcsolódva.
HIBA: api.onlineszamla.nav.gov.hu ‘[email protected],CN=e-Szigno SSL CA 2014,O=Microsec Ltd.,L=Budapest,C=HU’ által kiadott tanúsítványa nem ellenőrizhető:
  A kibocsátó hitelessége nem ellenőrizhető helyileg.
A(z) api.onlineszamla.nav.gov.hu géphez történő nem biztonságos kapcsolódáshoz használja a
„--no-check-certificate” kapcsolót.

Normál userként (opcionálisan rootként):

• Letölteni a cert-et innen
• Kicsomagolni és átnevezni a fájlt .crt kiterjesztésűre.

Root felhasználóként:

• bemásolni a fájlt a /usr/local/share/ca-certificates könyvtárba
• futtatni a update-ca-certificates parancsot
  Várt kimenet

root@tensorpc:/usr/local/share/ca-certificates# update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Adding debian:_.onlineszamla.nav.gov.hu_SSL_szerver.pem
done.
done.

Normál vagy rootként kipróbálni, hogy sikerült-e:

• parancssorban futtatni a következőt: wget https://api.onlineszamla.nav.gov.hu

pongraczi@tensorpc:~/tmp$ wget https://api.onlineszamla.nav.gov.hu
--2023-01-06 09:51:30--  https://api.onlineszamla.nav.gov.hu/
api.onlineszamla.nav.gov.hu (api.onlineszamla.nav.gov.hu) feloldása… 84.206.52.73
Csatlakozás a következőhöz: api.onlineszamla.nav.gov.hu (api.onlineszamla.nav.gov.hu)[84.206.52.73]:443… kapcsolódva.
HTTP kérés elküldve, várakozás válaszra… 200 OK
Hossz: 2 [text/plain]
Mentés ide: ‘index.html.1’

index.html.1                                                        100%[===================================================================================================================================================================>]       2  --.-KB/s    idő 0s     

2023-01-06 09:51:31 (1,49 MB/s) -- ‘index.html.1’ mentve [2/2]

És most örül. :)

from online-invoice.

Ez oké, de a meglevő, friss CA certekkel miért nem megy végig a SSL Certificate chain?

Lokális gépen (macos) nem kellett bemásolni a kiadott certet, simán lefut a curl.

from online-invoice.

@tsamu

Tegnap ugyanezzel szívtam.

A megoldás a következő volt Debian (bullseye) esetén:

wget https://onlineszamla.nav.gov.hu/api/files/container/download/certificate_20230105.zip
unzip certificate_20230105.zip
mv _.onlineszamla.nav.gov.hu_SSL_szerver.cer /usr/local/share/ca-certificates/api_onlineszamla_nav_gov_hu.crt
update-ca-certificates --fresh

Az áthelyezéskor az átnevezés szándékos, a zip-ben lévő fájlnéven nálam az update-ca-certificates --fresh nem foglalkozott vele.

Igen, ez Bullseye esetén működik, de Buster esetén már nem, ugyanúgy

* SSL certificate problem: unable to get local issuer certificate

from online-invoice.

@pongraczi nincs semmi gond az új cert-tel. A standartd szerint 13 hónap a cert maximális élettartama, évente megújítás lesz.

(Lehet a cert frissítést automatizálni is, de a standard szerint ez nem ajánlott, mert alternatív csatornán illik a cert-et beszerezni és frissíteni. Mi automatizáltuk ennek ellenére, mert a felhasználói oldalon nincs meg a megfelelően képzett ember alapanyag. Nálunk az auto frissítés után csak egy szolgáltatás restart kell, arra még képesek az emberek. Elvileg megoldható lenne hogy még restart se kelljen, de saját TrustManager kellene ahhoz, ami a felolvassa a friss cacerts-et)

(Hardcore módban nyílván egyszerűen figyelmen kívül is lehet hagyni a cert problémákat)

Köszönöm az infókat, a windows-os világ engem hidegen hagy, az alternatív beszerzésű cert telepítést megértem, ezt el tudom fogadni.
A cert-ek élettartama is rendben van, let's encrypt használóként nem igazán lepődök meg ezen, ez világos.
Viszont az, hogy egy világ képes működni úgy, hogy pl. a bankok felületének a https eléréséhez szükséges SSL tanúsítványt nem kell mindenkinek letölteni évente és telepíteni a gépére számomra barátságosabb megoldásnak tűnik, mint ez a hardcore, mágneslemezen az éjszaka leple alatt az egyik ügynök berakja egy kukába, másnap kiveszi a célszemély a kukából ügynökösdi.
Azt értem egyébként, hogy ez is egy döntés és akik a biztonsággal foglalkoznak, az ő döntésük, lehet, hogy nem kevés vitával (csak feltételezem).
Sőt, a honlap szerint ez a tanúsítvány már december közepétől elérhető volt, amire esetleg egy jól célzott cronnal fel is lehetett volna készülni.

Minden jó, ha a vége jó, most van debian és ubuntu megoldási lehetőség is, ha valakinek még gondot okoz.

Elnézést a "humorom" miatt, néha csak én gondolom, hogy humoros vagyok, a környezetem nem (biztos tumor).

from online-invoice.

Az áthelyezéskor az átnevezés szándékos, a zip-ben lévő fájlnéven nálam az update-ca-certificates --fresh nem foglalkozott vele.

Igen, ez Bullseye esetén működik, de Buster esetén már nem, ugyanúgy

* SSL certificate problem: unable to get local issuer certificate

Próbáljátok elolvasni a manualt, ott van tipp, mit kell tenni.
A --fresh kapcsolót nem használtam, lehet, nektek sem kellene.

from online-invoice.

Próbáljátok elolvasni a manualt, ott van tipp, mit kell tenni. A --fresh kapcsolót nem használtam, lehet, nektek sem kellene.

--fresh opció nélkül sem jó. Milyen manuálra gondolsz? Tudnál linket küldeni?

from online-invoice.

Szia @EPluribusUnum ! A főoldalról (https://onlineszamla.nav.gov.hu/home):

2023. január 5-én 17 órakor megújul az Online Számla éles és tesztrendszerében használt gép-gép interfészkapcsolat titkosító SSL-tanúsítványa. Az új tanúsítvány a Technikai információk/DokumentációkA linkre kattintva a tartalom új oldalon jelenik meg. menüpontban érhető el és tölthető le tömörített formában.

Szia @NTCA-supporter !

Hadd legyen néhány indiszkrét kérdésem.
Ezt a választ értelmezzem úgy, hogy minden nap nyissam meg a "Dokumentációk" weboldalt, és alaposan olvassam végig, tartalmaz e bármi olyan információt, ami a működtetés szempontjából kritikus?
A NAV birtokában van a számlázó szoftver fejlesztőjének elérhetősége.
Mi az akadálya annak, hogy az ilyen jellegű változásokról emailben, vagy az ügyfélkapun keresztül tájékoztatást kapjanak a fejlesztők?

from online-invoice.

debian stretch-en is kipróbáltam, pont ugyanezekkel a lépésekkel, pont ugyanúgy működik.
nem használtam --fresh kapcsolót.

from online-invoice.

Próbáljátok elolvasni a manualt, ott van tipp, mit kell tenni. A --fresh kapcsolót nem használtam, lehet, nektek sem kellene.

--fresh opció nélkül sem jó. Milyen manuálra gondolsz? Tudnál linket küldeni?

parancssorban: man update-ca-certificates

Vagy itt online egy.

Jogosultságra referencia:

root@postgres01:~# ls -al /usr/local/share/ca-certificates/
összesen 14
drwxrwsr-x 2 root staff    3 jan    6 10:43 .
drwxrwsr-x 7 root staff    7 júl    4  2017 ..
-rw-r--r-- 1 root root  3479 dec   22 15:26 _.onlineszamla.nav.gov.hu_SSL_szerver.crt

Esetleg a --verbose kapcsolóval futtatni, hátha az ad valamilyen információt.

Ezt kellene látni (a lényeg, az 1 added ):
root@bullseye:~/tmp# update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

from online-invoice.

debian stretch-en is kipróbáltam, pont ugyanezekkel a lépésekkel, pont ugyanúgy működik. nem használtam --fresh kapcsolót.

Se Stretch se Buster alattt sem működik. Bullseye-on jó csak.

$ docker run -it --rm debian:stretch
root@3a1bdf1961d7:/# apt-get update && apt-get -y upgrade
root@3a1bdf1961d7:/# apt-get install -y wget curl unzip
root@3a1bdf1961d7:/# wget https://onlineszamla.nav.gov.hu/api/files/container/download/certificate_20230105.zip
root@3a1bdf1961d7:/# unzip certificate_20230105.zip 
root@3a1bdf1961d7:/# mv _.onlineszamla.nav.gov.hu_SSL_szerver.cer /usr/local/share/ca-certificates/api_onlineszamla_nav_gov_hu.crt
root@3a1bdf1961d7:/# update-ca-certificates
root@3a1bdf1961d7:/# curl -v https://api.onlineszamla.nav.gov.hu
 Rebuilt URL to: https://api.onlineszamla.nav.gov.hu/
*   Trying 84.206.52.73...
* TCP_NODELAY set
* Connected to api.onlineszamla.nav.gov.hu (84.206.52.73) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate

from online-invoice.

@pongraczi szerintem te azért látod jónak, mert wget-el próbálod, azzal tényleg megy. Ebből a szempontból mindegy, mert lehet, hogy bugos a curl, de nekünk a NAV kliensünk perl LWP, ami szintén nem működik. Openssl is hibát ír:

# openssl s_client -showcerts -connect api.onlineszamla.nav.gov.hu:443
CONNECTED(00000003)
depth=0 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
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 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
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=HU/L=Budapest/O=Nemzeti Ad\xC3\xB3- \xC3\xA9s V\xC3\xA1mhivatal/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/[email protected]
-----BEGIN CERTIFICATE-----
..
..
..
-----END CERTIFICATE-----
---
Server certificate
subject=/C=HU/L=Budapest/O=Nemzeti Ad\xC3\xB3- \xC3\xA9s V\xC3\xA1mhivatal/CN=*.onlineszamla.nav.gov.hu/serialNumber=1.3.6.1.4.1.21528.2.3.2.7168
issuer=/C=HU/L=Budapest/O=Microsec Ltd./CN=e-Szigno SSL CA 2014/[email protected]
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 3069 bytes and written 334 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: DEA4C11FF2A8F5C347ECD19CDA711CCA82DF192BBE9011D0F27D00D4AA016CDB
    Session-ID-ctx: 
    Master-Key: C8EC4B85A5C29E6DAB792105CA666F58EFE305336BC25FBBCCA5E4203EBF6E22A4037C1B2C83B84240D84D85F3F949BD
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1672999636
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---

from online-invoice.

Én is úgy látom, hogy csak debian 11-től jó az egész, már ha debian. Dockerrel végigpróbálgattam a verziókat és hiába adom be a certet a curl-nak, nem működik 11-es előtt. Mi hiányzik vajon?

Pl ha az aktuális mappában van a letöltött cer fájl átnevezve nav.crt-re:

docker run --rm -it -v"`pwd`:/teszt" --workdir=/teszt debian:9 bash
apt update
apt install -y curl
curl --cacert nav.crt https://api.onlineszamla.nav.gov.hu

curl: (60) SSL certificate problem: unable to get local issuer certificate

Természetesen ha bemásolom a /usr/local/share/ca-certificates/ mappába és nyomok update-ca-certificates-et akkor sem lesz jobb (ezáltal persze bekerül a /etc/ssl/certs mappába a symlinkje), mert amúgy is megadtam a curl parancsnak a --cacert kapcsolóval, szóval ez nem a nem találásról szól.

Edit: Ahogy az első mondatomban céloztam rá, ha a debian:11 image-t használom, akkor megjelenik az OK kimenet hiba nélkül.

from online-invoice.

Nekem valami akkor sem kerek a certtel:

openssl s_client -connect api.onlineszamla.nav.gov.hu:443 -showcerts

CONNECTED(00000003)
depth=0 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
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 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
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 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
verify return:1
---
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 = [email protected]
-----BEGIN CERTIFICATE-----
MIIJ3........
...xk=
-----END CERTIFICATE-----
---
Server certificate
subject=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

issuer=C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = [email protected]

---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 3069 bytes and written 477 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: xxx
    Session-ID-ctx: 
    Master-Key: xxx
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1672998495
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---

ugyanez onlineszamla.nav.gov.hu esetén

openssl s_client -connect onlineszamla.nav.gov.hu:443 -showcerts

CONNECTED(00000003)
depth=2 C = HU, L = Budapest, O = Microsec Ltd., CN = Microsec e-Szigno Root CA 2009, emailAddress = [email protected]
verify return:1
depth=1 C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = [email protected]
verify return:1
depth=0 C = HU, L = Budapest, O = Nemzeti Ad\C3\B3- \C3\A9s V\C3\A1mhivatal, CN = *.nav.gov.hu, serialNumber = 1.3.6.1.4.1.21528.2.3.2.950
verify return:1
---
Certificate chain
 0 s:C = HU, L = Budapest, O = Nemzeti Ad\C3\B3- \C3\A9s V\C3\A1mhivatal, CN = *.nav.gov.hu, serialNumber = 1.3.6.1.4.1.21528.2.3.2.950
   i:C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = [email protected]
-----BEGIN CERTIFICATE-----
MIIJ
...xmv+lfG
-----END CERTIFICATE-----
 1 s:C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = [email protected]
   i:C = HU, L = Budapest, O = Microsec Ltd., CN = Microsec e-Szigno Root CA 2009, emailAddress = [email protected]
-----BEGIN CERTIFICATE-----
MIIGX...
MbK
mpQ=
-----END CERTIFICATE-----
 2 s:C = HU, L = Budapest, O = Microsec Ltd., CN = Microsec e-Szigno Root CA 2009, emailAddress = [email protected]
   i:C = HU, L = Budapest, O = Microsec Ltd., CN = Microsec e-Szigno Root CA 2009, emailAddress = [email protected]
-----BEGIN CERTIFICATE-----
MIIECj
...gnCW
-----END CERTIFICATE-----
---
Server certificate
subject=C = HU, L = Budapest, O = Nemzeti Ad\C3\B3- \C3\A9s V\C3\A1mhivatal, CN = *.nav.gov.hu, serialNumber = 1.3.6.1.4.1.21528.2.3.2.950

issuer=C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = [email protected]

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5674 bytes and written 441 bytes
Verification: OK

from online-invoice.

Én úgy láttam, hogy szükséges az e-Szigno SSL CA 2014 nevű Intermediate certifikációt is importálni, mert ez benne van a certifikáció láncban, az e-Szigno épp aktuális certifikációja viszont (ami "magától" működne) 2017-es.
Miután beimportáltuk a fentebbi kommentem alapján ezt a certifikációt is, azután elkezdett működni. Nem volt szükség onnantól curl insecure kapcsolóra, és hasonló mókusvakításokra.

Lehet hogy régebbi Debian-oknál is szükséges külön azt is importálni.

from online-invoice.

Én úgy láttam, hogy szükséges az e-Szigno SSL CA 2014 nevű Intermediate certifikációt is importálni, mert ez benne van a certifikáció láncban, az e-Szigno épp aktuális certifikációja viszont (ami "magától" működne) 2017-es. Miután beimportáltuk a fentebbi kommentem alapján ezt a certifikációt is, azután elkezdett működni. Nem volt szükség onnantól curl insecure kapcsolóra, és hasonló mókusvakításokra.

Akkor ahogy fent is látható, a sima onlineszamla.nav.gov.hu estén, ami szintén e-Szigno SSL CA 2014, miért fut végig a chain? Debian a legfrissebb, benne van az e-Szigno_Root_CA_2017.crt is.

from online-invoice.

Rosszul van beállítva a szerver, az e-szingó ellenőrzője szépen ki is írja: https://srv.e-szigno.hu/microsecssl&hosturl=api-test.onlineszamla.nav.gov.hu

A teljes tanúsítvány lánc leküldése a kliensnek NINCS beállítva

Hiba leírása
A megadott webszerver SSL beállításai NEM megfelelőek.

Kliens oldalon nem lehet az e-Szignó Hitelesítés Szolgáltató megbízható főtanúsítványáig felépíteni a tanúsítási láncot! A webszerver konfigurációjában nem került beállításra a teljes tanúsítvány lánc leküldése a kliens felé.

Az api.onlineszamla.nav.gov.hu -ra ugyanez.

from online-invoice.

Tehát az END USER certet be kell másolnom és akkor jó lesz, mert a teljes tanúsítvány lánc leküldése a kliensnek NINCS beállítva az api webszerveren.

wget https://onlineszamla.nav.gov.hu/api/files/container/download/certificate_20230105.zip
unzip ./certificate_20230105.zip
mv _.onlineszamla.nav.gov.hu_SSL_szerver.cer  /usr/local/share/ca-certificates/onlineszamla.nav.gov.hu_SSL_szerver.crt
update-ca-certificates

Csodás.

from online-invoice.

Javították, most már nem dob hibát... :) https://srv.e-szigno.hu/microsecssl&hosturl=api-test.onlineszamla.nav.gov.hu

Magyarán megint jobb lett volna nem csinálni semmit és várni, amíg magától megoldódik a probléma 😵‍💫

Pontosan 😂

from online-invoice.

@NTCA-supporter , a jövőben jó lenne ha nem 2 napos ablak lenne, hanem legalább 14 nap, de még jobb lenne a 31. (2 éjszaka esik a cert frissítés és a lejárat közé csak). Abban az ablakban kell az összes ügyfelünknek újraindítani a JVM-et a cert frissítés miatt.

Kedves @EPluribusUnum A tanúsítványokat amikor megkapta a NAV kihelyeztük még karácsony előtt, ez elég szerencsétlen időpont, de értjük a kérést, próbálunk majd ezen javítani.

Kedves Kollégák röviden reagálnék, tőmondatokban (lehet nem leszek népszerű)!

Kérem, hogy ne a NAV-ot ekézzétek azért, mert a különböző programok és operációs rendszerek különböző módon értelmezik és implementálják a tanúsítványkezelési szabványokat. A kiadott tanúsítványnak semmi baja nincs a világon.

Az hogy összekeveri valaki a böngésző működését egy gépi interfész működésével -> no komment!

Amit tapasztaltunk:
A program, vagy az operációs rendszer kulcstárából (nem file szinten), hiányzik a CA vagy lejárt. Ezért a lánc minden tagját oda importálni kell.
Az onlineszámla.nav.gov.hu és a api.onlineszamla.nav.gov.hu külön tanúsítvánnyal rendelkezik, a kettőnek nincs köze egymáshoz, Ergo az issuer nem biztos, hogy ugyan az.

A fent leírt hibának jelzett opció eddig sem volt beállítva, de most megkértük a kollégákat nézzék meg, most beállították.
Reméljük akkor legközelebb már nem lesz ilyen :)

Tanúsítvány frissítés minden évben lesz.

Nem kell minden nap megnyitni és elolvasni a portál tartalmat. Fel lehet az RSS feedre iratkozni (Portál jobb felső sarka ikon). Az jelzi, ha van új hír, bár nem a leg komfortosabban, de jelzi.

Köszi!

from online-invoice.

Javították, most már nem dob hibát... :) https://srv.e-szigno.hu/microsecssl&hosturl=api-test.onlineszamla.nav.gov.hu

Magyarán megint jobb lett volna nem csinálni semmit és várni, amíg magától megoldódik a probléma face_with_spiral_eyes

:))))))) Amikor meghallottam ezt a problémakört, pont ezt mondtam (zsigerből, gondolkodás és körbejárás nélkül), hogy ez nekem nem úgy tűnik, mintha a kliensek szalasztottak volna el valami mókolást.

Egyébként valaki meg tudja erősíteni, hogy a szolgáltatói oldalon történt egy kis csúszás (pl. elfelejtés foganatosítása) , vagy tényleg ennyit kell mókolni egy SSL tanúsítványért, aminek out of the box kellene működnie?

Találkozunk ugyanitt, ugyanveletek, 2024.12.22-e délután :)

from online-invoice.

There was no news if you are reading the page in english. :(

That's what I call problem!
Thank's it is true!

from online-invoice.

Az hogy összekeveri valaki a böngésző működését egy gépi interfész működésével -> no komment!

Nyugodtan lehet kommentelni, pl. engem nem érintett közvetlenül ez, ezért nem is igazán értettem, de ez csak annyit jelent, hogy én voltam oktondi (értsd, ostoba). Megesik. Agyat sem műtök.

Viszont inspirált a beszélgetés és van irány, mit tanuljak meg :) Bármilyen link erre jól jönne, legalább nekem, ahol ilyesmiről lehet tanulni (pl. más a gép-gép ssl és más a publikus ssl kezelése). Ha nincs, marad a duckduckgo.

from online-invoice.

Hmmmm, nekem még mindig nem gömbölyű valami (mivel buta vagyok, nem meglepetés).

Ilyen API https-en elérést készítettem már én is, többfélét (soap, rest), de azok vidáman működtek úgy a certet a letsencrypt biztosította (2-3 havonta megújul).
Ennek megfelelően a kliensek nem akadnak fenn azon, ha változik a cert és nem is kell tenniük semmit az égvilágon.

Amennyire beleolvastam a dokumentációba, az api és api-test nem más, mint egy REST interface, ahol http requestekkel operál a kliens. Ergo, kutyaközönséges cert kellene, ami spontán működik.

Javítsatok ki nyugodtan, de nekem úgy tűnik, mintha a certet ugyan korábban létrehozták az api-ra stb., de vagy műszaki probléma vagy emberi mulasztás/tévedés miatt valahol valami nem került lecserélésre, ami miatt nem lehetett hitelesíteni a megújított tanúsítványt, hanem mókolni kellett.
Amint kijavításra került valahol a hiba, spontán jó lett az új cert is anélkül, hogy bárkinek importálnia kellett volna bármit is.

Hol tévedek és miben? (szívesen tanulnék és kimondottan jó, hogy aktuális problémán keresztül lehet ezt megtenni)

from online-invoice.

@renced42 Akkor kérlek magyarázd el, hogy ha eddig sem volt beállítva az api webszerverren és a korábbi end user cert nem szerepelt a ca-certek között, akkor azon miért ment végig handshake az új cert esetén pedig miért nem. Tényleg érdekelne.

Kedves @tsamu
Csak ismételni tudom amit jeleztek a kollégák. Tehát, hogy pont nálad mi volt a baj, nem tudom.

from online-invoice.

Szerintem mindenhol ugyanaz volt a gond aki ide tévedt, nem csak nálam. Ezért vagyok kiváncsi arra, hogy miért ment gond nélkül a korábbi cert a meglévő összes, friss root és intermed certekkel end user cert nélkül.

from online-invoice.

Empirikusan: pár szerveremen kipróbáltam, ahol nem mókoltam semmit (centos/debian) és futtattam a wget-et, ami korábban elhasalt. Tökéletesen, ahogy várható volt, működött.

root@debian10:~# wget https://api.onlineszamla.nav.gov.hu
--2023-01-06 13:19:00--  https://api.onlineszamla.nav.gov.hu/
Resolving api.onlineszamla.nav.gov.hu (api.onlineszamla.nav.gov.hu)... 84.206.52.73
Connecting to api.onlineszamla.nav.gov.hu (api.onlineszamla.nav.gov.hu)|84.206.52.73|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2 [text/plain]
Saving to: ‘index.html’

index.html                                                          100%[===================================================================================================================================================================>]       2  --.-KB/s    in 0s      

2023-01-06 13:19:01 (2.69 MB/s) - ‘index.html’ saved [2/2]

Ebből én azt a következtetést vonom le, hogy nem a kliensekkel volt a gond, hanem a szolgáltatói oldalon történt hiba, ami miatt az itt jelenlévők pánikszerű mókolásba kezdtek, feltételezvén, hogy náluk van a hiba.

Illetve ha az volt a szolgáltatói oldalon a cél, hogy mindenki mókoljon, az az ötlet nem annyira vált be, akkor viszont érdemes lenne ezt a kényelmi funkciót a továbbiakban is fenntartani.

Én nem látom biztonságosabbnak, hogy le kell tölteni egy valamilyen certet ahhoz, hogy elfogadja a szerver certjét, kontra Microsect, GoDaddy, Letsencrypt, bárki más szolgáltató által biztosított hitelesítés. Mert ha úgy gondoljuk, hogy nem megbízhatóak ezek a szolgáltatók, akkor úgy generálisan az egész koncepció teljesen felesleges és megbízhatatlan.

from online-invoice.

@renced42 Akkor kérlek magyarázd el, hogy ha eddig sem volt beállítva az api webszerverren és a korábbi end user cert nem szerepelt a ca-certek között, akkor azon miért ment végig handshake az új cert esetén pedig miért nem. Tényleg érdekelne.

Kedves @tsamu Csak ismételni tudom amit jeleztek a kollégák. Tehát, hogy pont nálad mi volt a baj, nem tudom.

A , nem tudom nem kellett volna.

• vagy benéztek a kollégáid valamit, csúnyán,
• vagy volt egy meeting, ahol az az ötlet nyert, hogy sokkal biztonságosabb, ha mindenki letölti a crt-t és telepíti magának, hogy elfogadja majd az új tanúsítványt, mert úgy milyen biztonságos és emiatt került elő a szopóálarc a korán ébredőknek
• vagy mindenki más butuska
• egyéb megoldások

Nem tudom, melyik a jobb.

</humor off>

from online-invoice.

Kedves @omachtandras

Köszönjük a jelzést!

from online-invoice.

A fenti dockeres példám is hirtelen megjavult, de azért fura, hogy az új (11-es) debianon miért ment ez hiba nélkül 🤷‍♂️ Pedig az openssl s_client -connect api.onlineszamla.nav.gov.hu:443 -showcerts parancs azon is azt írta, hogy cannot verify cert (javítás óta Verification: OK).

Mindenesetre most már egészen régi debianokon is jónak tűnik 👌

from online-invoice.

A fenti dockeres példám is hirtelen megjavult, de azért fura, hogy az új (11-es) debianon miért ment ez hiba nélkül man_shrugging Pedig az openssl s_client -connect api.onlineszamla.nav.gov.hu:443 -showcerts parancs azon is azt írta, hogy cannot verify cert (javítás óta Verification: OK).

Mindenesetre most már egészen régi debianokon is jónak tűnik ok_hand

Szerintem ott a docker maga volt a probléma, a konténer belsejét nem tudod frissíteni.
Esetleg a 11-esnél a megfelelő tárhelyek külső, permanens helyen vannak (találgatok).

Indirekten bizonyítva, nem a debiannal lehetett problémád, mert ahol én kipróbáltam régi debiannal (9), ugyanaz, ugyanúgy működött.

from online-invoice.

Más.
Machine 2 machine SSL.
Én valahogy továbbra sem látok technikai különbséget, hogy böngészőben írok be egy címet és megkapom az OK-t, vagy wget vagy curl-t használok api elérésre, netalán mindezt programból teszem meg.
Technikailag pontosan ugyanúgy működik mindegyik: kézfogásnál előjön a cert, azt megnézzük, jó-e. A világ ilyenkor a korábban írt + egyéb szolgáltatók CA-ját használja, mondván, az megbízható.
Egyéb esetben, amit nem javasolnak production-ban, az a self-signed cert használata, ahol vagy ignoráljuk a hibát, vagy mókolunk a kliensen.

Tehát hogy gép-gép, gép-ember, teljesen mindegy, ez csak elnevezés, mókusvakítás, stb.

Tévednék valamiben? Komolyan kérdezem, mert vagy csúnyán elnéztem valamit vagy tényleg csak porhintés (technikai oldalról, nem sales oldalról).

from online-invoice.

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

from online-invoice.

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

from online-invoice.

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 = [email protected]

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

from online-invoice.

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: #1027 (comment)
Ebben pedig látszólag nincs ott csak 1db cert-et tartalmaz (egy másik commentben is ilyet láttam).

from online-invoice.

@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?

from online-invoice.

@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

from online-invoice.

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

from online-invoice.

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

from online-invoice.