Známé problémy

V následujícím textu naleznete známé problémy nebo problémové odpovědi, na které můžete narazit při implementaci služeb SecuSign SDK.

Validate

V této kapitole jsou uvedeny problémy týkající se metod služby SecuSign Validate pro ověřování kvalifikovaných podpisů.

Timestamp error ORDER FAILURE

K tomuto chybovému stavu dochází v případě, že časové razítko bylo vydáno po času ověření. Většinou je to z důvodu nesynchronizovaného času volajícího a serveru časových razítek. Případně je třeba nastavit čas ověření po času získání časového razítka – to má čas dle atomických hodin, ale nikoliv z budoucna.

Preserve

V této kapitole jsou uvedeny problémy týkající se metod služby SecuSign Preserve pro uchování kvalifikovaných podpisů.

Document does not comply with conditions for LTV. At least one signature must be marked as VALID

Dokument zaslaný do služby uchování (Preserve) nesplňuje všechny podmínky. Většinou je podpis / pečeť v dokumentu příliš čerstvý/čerstvý, neobsahuje časové razítko nebo se nejedná o podpis/pečeť založený/založenou na kvalifikovaném certifikátu.

Seal (vzdálené pečetění/podepisování)

V této kapitole jsou uvedeny problémy týkající se metody SecuSign Seal pro Vzdálené podepisování / pečetění.

Selected certificate not found

K této návratové chybě dochází v případě, že certifikát se specifikovaným identifikátorem certifikátu (CertificateID) volajícím, nebo výchozím, definovaným ve volání SecuSign metody Seal, nebyl nalezen v bezpečném prostředku.

Je třeba ověřit a znovu správně specifikovat CertificateID ve volání metody Seal.

Access Denied

K uvedené chybové zprávě dojde v případě, že volající správně specifikoval identifikátor certifikátu (CertificateID), ale uživatel, specifikovaný v parametrech volání, resp. Autentizovaný ke službě, k tomuto certifikátu nemá oprávnění přístupu.

Je třeba ověřit zvolenou kombinaci CertificateID a autentizovaného uživatele, např. opětovným přihlášením uživatele a nabídkou získaných certifikátů ve volající aplikaci.

Invalid PIN

K této chybě dochází v případě, že volající správně specifikoval identifikátor certifikátu, autentizovaný uživatel služby k němu má přístup, ale zadané heslo (PrivateKeyPIN) neodpovídá nastavenému.

Je třeba vyzvat autentizovaného uživatele ke znovu zadání správného hesla (PrivateKeyPIN) pro vybraný certifikát (CertificateID).

Error decrypting data to be signed

Chyba nastává v případě, kdy na backendové službě Vzdáleného podepisování / pečetění není odpovídajícím způsobem správně nakonfigurován přístup pro zákazníka služby, konkrétně (licenční / autentizační) certifikát pro dešifrování příchozích dat k podpisu.

Je třeba kontaktovat projektového / obchodního manažera Software602 a.s.

SYSTEM status code 413: Request Entity Too Large

Chyba nastává v případě, kdy v požadavku přijde větší velikost obsahu, než jaký je v rámci webového serveru povolen pro načtení do vyrovnávací paměti a předání do rozšíření resp. Modulu ISAPI.

Řešením je navýšit hodnotu uploadReadAheadSize v konfiguraci daného webu.

Postup pro navýšení:

Správce IIS > nazev_WebSite > Konfigurace (Configuration Editor) > v prostředním okně nahoře přepnout na systém.webServer/serverRuntime a tam navýšit hodnotu:

uploadReadAheadSize (byte; výchozí 49152).

Zvolená hodnota uploadReadAheadSize (byte) by po přepočtu měla zhruba odpovídat nastavené hodnotě maxRequestEntityAllowed (byte). Zároveň je třeba volit takovou hodnotu, která nezahltí paměť serveru. Příklad: uploadReadAheadSize = 136314, tedy maxRequestEntityAllowed = 136314000.

TimeStamp

V této kapitole jsou uvedeny problémy týkající se metody SecuSign TimeStamp pro získání kvalifikovaného elektronického časového razítka.

Could not create SSL/TLS secure channel. User: IIS APPPOOL\SecuSign. Status: SecureChannelFailure

Komunikace se vzdálenými servery časových razítek probíhá skrze zabezpečený SSL/TLS kanál na základě certifikátu nebo jména hesla. V případě, že nepodaří vytvořit zabezpečený kanál SSL/TLS, je třeba zkontrolovat:

Licenční certifikát – zda je platný (viz EXPIRES=.. v debugLog), korektně nastavený (cesta/heslo) a aktivovaný na 602 ID účtu zákazníka.
Autentizační certifikát – zda je platný (viz EXPIRES=.. v debugLog), korektně nastavený (cesta/heslo) a aktivovaný na 602 ID účtu zákazníka, resp. na účtu u poskytovatele časových razítek.
Pokud je specifikován pomocí TSA_CertHash, pak zkontrolovat:
- Zda je instalovaný ve Windows certificate store pro celý počítač (LOCAL_COMPUTER) a je k němu nastaven přístup pro aplikační pool služby, nebo uživatele aplikačního poolu služby.
- Nebo zda je instalovaný ve Windows certificate store (CURRENT_USER) pod uživatelem aplikačního poolu služby.
Nastavení zabezpečení v operačním systému – Možnosti Internetu (inetcpl.cpl) > Upřesnit > Zabezpečení > Používat protocol SSL/TL.
- Ověřit, jaké protokoly podporuje volaný server časových razítek. V případě SecuSign jsou to TLS 1.2 a TLS 1.3.
Nastavení komunikace po novějších šifrovacích protokolech TLS 1.2.
- Do konfigurace webové služby (soubor Web.config) v elementu httpRuntime nastavit verzi .NET Framework verzi 4.6.2 nebo vyšší.
  Příklad:
  <httpRuntime maxRequestLength="133120" executionTimeout="360" targetFramework="4.7.2"/>
Prostup na URL serveru časových razítek např. skrze firewall nebo proxy.
- Při nutnosti použití proxy serveru je třeba ho nastavit podle kapitoly Proxy server.
Zda je v případě čerpání vlastních časových razítek (TSA_URL + TSA_EnableURL) nainstalovaný kořenový certifikát vystavitele volaného vzdáleného serveru (SSL) časových razítek ve Windows certificate store > Trusted root authorities.
Zda je nainstalovaný kořenový certifikát vystavitele autentizačního certifikátu použitého pro čerpání časových razítek (viz druhý bod) ve Windows certificate store > Trusted root authorities.

Chyba při autentizaci klientským certifikátem, kdy dojde k chybě: ERR_CONNECTION_RESET nebo 403 Forbidden

Při nastavení autentizace klientským certifikátem může dojít k následujícím chybám.

Příznaky:

U webové služby je nastaveno Vyžadování SSL a klientského certifikátu.
V browseru se při přístupu na stránku Default.asmx místo seznamu metod vrací buď chyba ERR_CONNECTION_RESET nebo 403 Forbidden.
Utilita CliCertAuth.zip vrací při volání GetVersionInfo chybu 403 Forbidden.
v IIS logu je chyba 403 16 2148204809, přičemž 2148204809 = 0x800B0109 = CERT_E_UNTRUSTEDROOT.
Nepomůže zařazení rootu autentizačního certifikátu do LocalComputer\TrustedRoot.
Projevilo se na Windows Server 2022, ale problém s TrustedRoot může být zřejmě i na Windows Server 2012 nebo 2016.

Popis problému:

Příliš přísná implementace TLS 1.3, viz Windows Server 2022, IIS Certificate Authentication not working: Microsoft implemented TLS 1.3 in most secure way by RFC. IIS wants to perform post-handshake authentication. Unfortunately common browsers do not support it in default configuration. So, de facto IIS default configuration for two-way SSL with common browsers do not work with IIS when TLS 1.3 only is enabled.
Přítomnost non-self-signed certifikátů v LocalComputer\TrustedRoot, viz IIS may reject client certificate requests with HTTP 403.7 or 403.16 errors.

Řešení:

Na Windows Server 2022 v nastavení webu > Vazby (Bindings) > Upravit zaškrtnout volbu Zakázat protokol TLS 1.3 přes TCP.
Spustit PowerShell skript
Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object \{$.Issuer -ne $.Subject} | Format-List * | Out-File "c:\computer_filtered.txt"
pro zjištění non-self-signed certifikátů v LocalComputer\TrustedRoot a pokud nějaké certifikáty vypíše, odstranit je.

HSTS (HTTP Strict Transport Security)

V rámci vylepšování zabezpečení služeb je vhodné na službách nastavovat HSTS.

Dokumentace: https://infosec.mozilla.org/guidelines/web_security#http-strict-transport-security.

Nastavení v IIS je u konkrétního webu nastavení HSTS (novější než windows 2012).

Tato položka nastaví v C:\Windows\System32\inetsrv\Config\applicationHost.config v elementu sites/site pro příslušný web element:
```
<hsts enabled="true" max-age="63072000" includeSubDomains="true" preload="true" redirectHttpToHttps="true" />
```

Pro Windows 2012 je nastavení následující:

Které ve web.config přidá do system/webServer element do customHeaders:

  <httpProtocol>
    <customHeaders>
      <add name="Strict-Transport-Security" value="max-age=63072000; includeSubDomains; preload" />
    </customHeaders>
  </httpProtocol>

Popis je v kapitole Zabezpečení a omezení SDK serveru. Test nastavení je možný pomocí https://observatory.mozilla.org/. Případně také https://securityheaders.com/.

Zákaz přístupu botům pro WS dostupnou z internetu

Jakýkoli web vystavený do internetu mohou vyhledat a procházet (crawler) roboti, kteří se zaměřují na sběr dat pro indexace nového obsahu (do vyhledávačů), kontrolu funkčnosti odkazu (pro ladění webů) a (nebo) sběr emailových adres (pro rozesílání spamu).

Přístup takovým robotům je třeba upravit pomocí souboru robots.txt (název musí být malými písmeny!). Jedná se o jednoduchý textový soubor (viz přípona .txt), který by měl být uložen v kódování UTF-8 bez BOM a řádky mají být oddělené pomocí CR, CR/LF nebo LF (tak to vyžaduje např. bot od Googlu, viz: https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt#file-format).

Na službách je tedy vhodné zakázat přístup všem botům do všech úrovní stránek webu. V takovém případně je obsahem souboru robots.txt:

User-agent: *
Disallow: /

Soubor stačí nahrát do výchozí složky daného webu, např. C:\qs\WebService, a platí pro všechny služby běžící pod daným webem. Pokud je chtěno některé z nich vyloučit (a nechat prohledávat), pak je nutné tyto weby specifikovat, viz: https://www.jakpsatweb.cz/robots-txt.html.