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)

NTCA-supporter commented 1 year ago

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

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

EPluribusUnum commented 1 year ago

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

tsamu commented 1 year ago

Debian alatt eddig jó volt, most ezt dobja:

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

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.

kodfoso commented 1 year ago

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

pongraczi commented 1 year ago

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.

EPluribusUnum commented 1 year ago

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

pongraczi commented 1 year ago

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 ‘emailAddress=info@e-szigno.hu,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):

Root felhasználóként:

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`  

```bash
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. :)

tsamu commented 1 year ago

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.

neszt commented 1 year ago

@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
pongraczi commented 1 year ago

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

pongraczi commented 1 year ago

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.

neszt commented 1 year ago

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?

imanzuk commented 1 year ago

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

  1. 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?

pongraczi commented 1 year ago

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.

ijnpcsupport commented 1 year ago

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.

pongraczi commented 1 year ago

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.

neszt commented 1 year ago

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
neszt commented 1 year ago

@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/emailAddress=info@e-szigno.hu
-----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/emailAddress=info@e-szigno.hu
---
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
---
slaci commented 1 year ago

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

tsamu commented 1 year ago

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 = info@e-szigno.hu
-----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 = info@e-szigno.hu

---
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 = info@e-szigno.hu
verify return:1
depth=1 C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = info@e-szigno.hu
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 = info@e-szigno.hu
-----BEGIN CERTIFICATE-----
MIIJ
...xmv+lfG
-----END CERTIFICATE-----
 1 s:C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = info@e-szigno.hu
   i:C = HU, L = Budapest, O = Microsec Ltd., CN = Microsec e-Szigno Root CA 2009, emailAddress = info@e-szigno.hu
-----BEGIN CERTIFICATE-----
MIIGX...
MbK
mpQ=
-----END CERTIFICATE-----
 2 s:C = HU, L = Budapest, O = Microsec Ltd., CN = Microsec e-Szigno Root CA 2009, emailAddress = info@e-szigno.hu
   i:C = HU, L = Budapest, O = Microsec Ltd., CN = Microsec e-Szigno Root CA 2009, emailAddress = info@e-szigno.hu
-----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 = info@e-szigno.hu

---
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
ijnpcsupport commented 1 year ago

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

tsamu commented 1 year ago

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

neszt commented 1 year ago

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é.
imanzuk commented 1 year ago

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.

connorhu commented 1 year ago

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

tsamu commented 1 year ago

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.

gothe92 commented 1 year ago

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

tsamu commented 1 year ago

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 😵‍💫

lxndralbert commented 1 year ago

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 😂

renced42 commented 1 year ago

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

MatevzSe commented 1 year ago

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

connorhu commented 1 year ago

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.

pongraczi commented 1 year ago

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

renced42 commented 1 year ago

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

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

pongraczi commented 1 year ago

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.

tsamu commented 1 year ago

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

pongraczi commented 1 year ago

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)

renced42 commented 1 year ago

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

tsamu commented 1 year ago

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.

pongraczi commented 1 year ago

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.

neszt commented 1 year ago

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

pongraczi commented 1 year ago

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

Nem tudom, melyik a jobb.

</humor off>

omachtandras commented 1 year ago

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!

renced42 commented 1 year ago

Kedves @omachtandras

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

slaci commented 1 year ago

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 👌

pongraczi commented 1 year ago

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.

connorhu commented 1 year ago

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:

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.

EPluribusUnum commented 1 year ago

@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

pongraczi commented 1 year ago

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

amargo commented 1 year ago 
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 = info@e-szigno.hu
verify return:1
depth=1 C = HU, L = Budapest, O = Microsec Ltd., CN = e-Szigno SSL CA 2014, emailAddress = info@e-szigno.hu
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