IIS veebiserverile ID-kaardi toe seadistamine

In English

Versioon: 26.04/1

Väljaandja: RIA

Versiooni info

Kuupäev	Versioon	Muutused/märkused
21.01.2019	19.01/1	Avalik versioon, baseerub 18.12 tarkvaral.
12.02.2019	19.02/1	Lisatud OCSP konfiguratsioonivõimalused. — Muutja: Urmas Vanem
01.10.2019	19.10/1	Lisatud info Windows serveri (IIS) paranduste staatuse ja tulevase kättesaadavuse osas versioonide lõikes. Vt. sissejuhatuse viimane lõik. — Muutja: Urmas Vanem
18.10.2019	19.10/2	Kirjeldatud Windows Server 2016 uuendus KB4516061, mis lahendab Chrome-IIS probleemi. — Muutja: Urmas Vanem
08.11.2019	19.11/1	Kirjeldatud Windows Server 2019 uuendus KB4520062, mis lahendab Chrome-IIS probleemi. — Muutja: Urmas Vanem
14.11.2019	19.11/2	Kirjeldatud Windows Server 1903 (SAC) uuendus KB4524570, mis lahendab Chrome-IIS probleemi. — Muutja: Urmas Vanem
12.12.2019	19.12/1	Lisatud soovitused IIS’i turvamiseks. — Muutja: Urmas Vanem
14.12.2020	20.12/1	Lisatud turvasätted ebasoovitavate CA-de ligipääsu piiramiseks. — Muutja: Urmas Vanem
17.12.2020	20.12/2	Lisatud mõned turvasoovitused peatükki „Ebavajalike CA-de juurdepääsu piiramine”. — Muutja: Urmas Vanem
03.03.2021	21.03/1	Eemaldatud aegunud IIS ja Google Chrome autentimise probleem ning täpsustatud infot. — Muutja: Kristjan Vaikla
30.04.2021	21.04/1	Eemaldatud aegunud ESTEID-SK 2011 sertifikaatide tugi. — Muutja: Urmas Vanem
14.12.2021	21.12/1	Muudetud Windows platvorm versioonile Server 2022. Lisatud kolmandalt osapoolelt ECDSA algoritmil põhineva sertifikaadi päringu protseduur. Täiendatud on TLS ja Cipher soovitusi. — Muutja: Urmas Vanem
18.01.2022	22.01/1	Lisatud Windows Server 2022 ja TLS 1.3 protokolliga seotud informatsioon, k.a. in-handshake autentimismeetodi konfigureerimise protseduur sertifikaadiga autentimise lubamiseks TLS 1.3 protokolliga. — Muutja: Urmas Vanem
18.12.2023	23.12/1	Eemaldatud ESTEID-SK 2015 ahel. — Muutja: Urmas Vanem
31.10.2025	25.10/1	Lisatud Zetes ahelad. — Muutja: Raul Kaidro
22.04.2026	26.04/1	Konverteeritud Markdown formaati. — Muutja: Raul Metsma

Juhend, kuidas autentida kasutajat IIS veebiserveril Eesti eID kaartidega.

---

• IIS veebiserverile ID-kaardi toe seadistamine
  • Sissejuhatus
  • Ühepoolse SSL/TLS-i konfigureerimine
    • Windows serveri sertifikaadi konfiguratsioon
      • Serveri sertifikaadi hankimine
        • Sakk General
        • Sakk Subject
        • Sakk Extensions
        • Sakk Private Key
      • Sertifikaadi installeerimine
    • Ühepoolse SSL-konfiguratsiooni loomine
      • HTTP ligipääsu piiramine
  • Kahepoolse SSL-i, sertifikaadiga autentimise nõudmine
    • Eelhäälestus
    • Eesti eID sertifikaatide häälestus IIS serveril
    • In-handshake autentimismeetodi lubamine
    • Autentimine
  • Võimalikud lisakonfiguratsioonid
    • Kasutajapoolsete sertifikaatide filtreerimine
    • Kliendisertifikaatide kehtivuse kontroll OCSP teenuse vastu
    • Soovituslikud IIS’i sätted
      • SSL/TLS
      • Šifrikomplektid (Cipher suites)
        • Muud konfigureeritavad Schannel omadused
      • Muud võimalused

Sissejuhatus

Käesolev juhend kirjeldab IIS veebiserveri konfiguratsiooni kahepoolse SSL-i kasutamiseks, kus kliendi poolseks sertifikaadiks on Eesti eID kaardile (ID-kaart, elamisloakaart, digi-ID ja e-residendi digi-ID) väljastatud sertifikaat.

Juhendi loomisel on kasutatud Windows Server 2022 ja Windows 10 operatsioonisüsteeme. Näidisjuhendis on toetatud SK ID Solutions EE-GovCA2018 ja Zetes EEGovCA2025 ahelast pärinevad sertifikaadid. Tagamaks sertifikaatide äratundmist on kohustuslikuks komponendiks kliendi poolel ka ID-tarkvara¹. Näidisjuhendi serveri sertifikaat on väljastatud OctoX testkeskkonnast.

IIS kasutamisel on võimalik rakendada erinevaid autentimismeetodeid. Käesolev dokument vaatleb sertifikaadi nõude kehtestamist IIS anonüümse autentimise jaoks – st. peale sertifikaadi kehtivuse kontrolli lubatakse kasutaja eelnevalt määratud kasutaja (IUSR) õigustes veebisaidile ligi.

Hetkel on testid edukalt läbi viidud järgmiste brauseritega (viimased versioonid):

1. Microsoft Edge
2. Mozilla Firefox
3. Google Chrome

Ühepoolse SSL/TLS-i konfigureerimine

Windows serveri sertifikaadi konfiguratsioon

Pakkumaks turvalist veebiteenust peab IIS serverile olema määratud TLS sertifikaat — käesolevas näites on kasutusel OctoX testkeskkonnast väljastatud sertifikaat. Samuti peavad nii kliendid kui ka veebiserver ise usaldama nimetatud sertifikaati.

Domeeni keskkonnas ja domeeni (enterprise) CA olemasolul on tõenäoliselt kõige mõistlikum küsida ka serveri sertifikaat domeeni CA-lt. Ent juhul, kui meid ei rahulda domeeni taseme turvalisus ja võimalused või kui vajame sertifikaati, mis on laiemalt usaldatud, tuleb luua privaatvõti ning sertifikaadi päring ja lasta viimase alusel luua sertifikaat mõnel üldtuntud CA-l.

Serveri sertifikaadi hankimine

Kuna IIS halduskonsoolilt loodav sertifikaadi päring on üsna piiratud võimalustega, kasutatakse serveri sertifikaadi loomiseks hoopis sertifikaatide halduskonsooli. Käivitage IIS serveril mmc.exe ja lisage sinna lokaalse arvuti sertifikaadid. Looge kohandatud päring:

Klikkige kolm korda Next ja valige Details, Properties. Avaneb sertifikaadi päringu omaduste aken:

Järgnevalt on võimalik määrata päringufailile täpsed omadused, milliseid soovitakse hiljem veebiserveri sertifikaadi juures näha.

Juhul, kui sarnaseid päringufaile on tarvis tihedamini luua, soovitatakse tegevuse automatiseerimiseks tutvuda PowerShell võimalustega.

Sakk General

Siin on võimalik määrata soovi korral sertifikaadi hüüdnimi ja põgus kirjeldus. Need väljad ei ole sertifikaadi sisulised osad ja omavad tähendust selgituse, hilisema lihtsama arusaama mõttes.

Sakk Subject

Aknas Subject kirjeldatakse subjekt nagu ikka. Kui soovitakse kasutada erinevaid SAN DNS nimesid või common name puhul kasutatakse midagi muud kui FQDN, siis tuleb üks või mitu DNS aliast siin ka kirjeldada.

Sakk Extensions

Aknas Extensions tuleb määrata järgmised omadused:

1. Key Usage:
   1. Digital signature;
   2. Key encipherment.
2. Extended Key Usage:
   1. Server Authentication.

Sakk Private Key

Siit aknast valitakse CSP ehk sertifikaadi võtmete algoritm. Näidis-konfiguratsioonis kasutatakse algoritmi ECDSA_P256, seega valitakse loendist ECDSA_P256 ja eemaldatakse nimekirja alguses olev RSA.

Klikkige OK ja Next, määrake kaust ning nimi ja salvestage sertifikaadi päring Base64 formaadis.

Värskelt loodud sertifikaadi päringufaili omadused on võimalik kontrollida käsuga certutil -dump PÄRINGUFAILI_NIMI.

Tuleb veenduda, et ka DNS alternatiivsed nimed on päringufailis olemas:

Sertifikaadi päringufail edastatakse mõnele CA serverile, paludes selle alusel sertifikaat genereerida. Tulemus on järgmine:

Sertifikaadi installeerimine

IIS server peab usaldama sertifikaati OctoX Demo CA 21.11, mis on serveri sertifikaadi väljastajaks. Selleks tuleb kontrollida selle sertifikaadi olemasolu usaldusväärsete juursertifikaatide² konteineris. Kui väljastaja CA sertifikaat sealt puudub, tuleb see lisada!³

IIS serveri sertifikaat ise tuleb paigaldada IIS serveril lokaalse arvuti personaalsesse konteinerisse:

Ühepoolse SSL-konfiguratsiooni loomine

Ühepoolse SSL-i kehtestamiseks peab veebisaidil olema kirjeldatud SSL port (vaikimisi 443) ja see peab olema seotud soovitava sertifikaadiga. Koheselt tuleb keelata ka vanade SSL/TLS protokollide (vanemad kui 1.2) kasutamine!

Peale määrangute kinnitamist ühepoolne SSL töötab!

Ühepoolse SSL-i demonstreerimiseks kasutatud Firefox veebilehitseja näitab lisainfo akendes veel ka järgmist:

1. Kasutusel on värskelt installeeritud sertifikaat 2111.kaheksa.xi;
2. Kasutusel on TLS 1.3 protokoll.

HTTP ligipääsu piiramine

HTTP ligipääsu keelamiseks eemaldatakse port 80 seotud protokollide loendist ja keelatakse tulemüürist ka vastav ligipääs. Alternatiivina on võimalik suunata HTTP liiklus automaatselt HTTPS saidile, vältimaks probleemi, kus kasutajad kirjutavad ise brauserisse saidi aadressi ent ei taipa sinna ette HTTPS:// määrangut panna.

Kahepoolse SSL-i, sertifikaadiga autentimise nõudmine

Eelhäälestus

Märkus: IIS 10/Schannel, mis töötab Windows Server 2022 platvormil, kasutab sertifikaadiga autentimiseks protokolli TLS 1.3 abil vaikimisi post-handshake autentimismeetodit (kehtib alates 2022. aastast, aktuaalne ka 2026. aastal). Kuna aga enimlevinud brauserid seda ei toeta⁴, siis see lahendus paraku praktikas ei tööta! Juhul, kui TLS 1.3 on sisse lülitatud, ei saada server kliendile vaikimisi konfiguratsioonis sertifikaadi päringut ja katkestab ühenduse! Sertifikaadiga autentimise tööle saamiseks tuleb keelata TLS 1.3 kasutamine. Alternatiivina saab sisse lülitada in-handshake autentimismeetodi, vt. peatükk „In-handshake autentimismeetodi lubamine”.

Märkus: Windows Server 2025 platvormil on see probleem lahendatud — IIS lisab HTTPS-seose seadistustesse „Negotiate Client Certificate” märkeruudu, mis võimaldab in-handshake autentimist otse liidesest ilma allpool kirjeldatud netsh käsuta.

TLS 1.3 protokolli versiooni saab välja lülitada IIS HTTPS seose lehelt, märkides linnukese lahtrisse Disable TLS 1.3 over TCP:

Eesti eID sertifikaatide häälestus IIS serveril

Kahepoolse SSL-i lubamiseks tuleb IIS serveri poolt nõuda sertifikaadiga autentimist. Vaikimisi lubab server enda poole pöördumisel kasutada kõiki sertifikaate, mis on tema poolt usaldatud ja millel on EKU-s kirjeldatud client authentication laiend. Korrektseks toimimiseks peab server suutma luua kogu sertifikaadiahela alates kasutajasertifikaadist kuni juursertifikaadini – see tähendab, et lisaks juurtaseme sertifikaatide olemasolule IIS serveris on vajalik ka kesktaseme (intermediate) sertifikaatide olemasolu.

IIS serveris tuleb sertifikaadid publitseerida järgmiselt:

1. Usaldusväärsete juursertifikaatide konteinerisse:
   1. EE-GovCA2018 (https://c.sk.ee/EE-GovCA2018.der.crt)
   2. EEGovCA2025 (https://crt.eidpki.ee/EEGovCA2025.crt)
2. Kesktaseme sertifikaatide konteinerisse⁵:
   1. ESTEID2018 (http://c.sk.ee/esteid2018.der.crt)
   2. ESTEID2025 (https://crt.eidpki.ee/ESTEID2025.crt)

Veebisaidi SSL omaduste alt tuleb nõuda SSL protokolli ja kliendi sertifikaatide kasutamist:

Loodud konfiguratsioon lubab veebisaidile ligipääsu 443 pordi kaudu, kasutajalt nõutakse sertifikaati. Pöördudes veebisaidi poole lubatakse valida soovitav serveri poolt aktsepteeritud sertifikaat:

Peale PIN-i sisestamist kontrollitakse sertifikaadi kehtivust veebiserveri poolt ja kui kõik on korras, lastakse kasutaja veebisaidile ligi.

Alternatiivina võib IIS-i poolse sertifikaadinõude (Require) asemel kasutada ka lihtsat sertifikaadi aktsepteerimist (Accept) IIS serveri poolt – see võimaldab lisaks sertifikaadile saada serverile ligi ka kasutajanime ja parooliga või üldse autentimata.

In-handshake autentimismeetodi lubamine

Kui soovitakse siiski kasutada TLS 1.3 protokolli ja sertifikaadiga autentimist, saab lubada in-handshake autentimismeetodi. Selle meetodi puhul küsib server kliendilt Server Hello saatmisel koheselt ka sertifikaati.

In-handshake autentimismeetodi lubamiseks tuleb teha järgmist:

1. Dokumenteerida olemasoleva sertifikaadi määrangud käsuga netsh http show sslcert. Oluline on üles märkida Certificate Hash ja Application ID:

   

2. Eemaldatakse sertifikaadi seotus 443 pordiga käsuga netsh http del sslcert 0.0.0.0:443:

   

3. Sertifikaat lisatakse uuesti, lubades ühtlasi ka in-handshake autentimismeetodi käsuga netsh http add sslcert ipport=0.0.0.0:443 certhash=312bbb70898b5ae10753998c67bceeeb97d49f79 appid={4dc3e181-e14b-4a21-b022-59fc669b0914} certstorename=MY clientcertnegotiation=Enable:

   

Vaadates uuesti sertifikaadi infot, on näha, et Negotiate Client Certificate on nüüd lubatud:

Märkus: Kuna session renegotiation on TLS 1.3 puhul keelatud, siis selle meetodi puhul tuleb arvestada asjaoluga, et autentimine peab toimuma „esimesel lehel”. Kui ühepoolne SSL ühendus on juba kliendi sertifikaadiga autentimata loodud ja samal lehel soovitakse kliendi sertifikaadiga autentides mõnele kaitstud ressursile ligi pääseda, siis see ebaõnnestub, kuna TLS 1.3 ei toeta sellist lähenemist. Vajadusel tuleb see „maandumise” probleem ühel või teisel viisil lahendada.

Autentimine

Käesolevas näites on lubatud ainult anonüümne autentimine:

Võimalikud lisakonfiguratsioonid

Selle dokumendi eesmärgiks ei ole anda täpseid juhiseid optimaalseks veebisaitide konfigureerimiseks ega turvamiseks. Pigem tutvustatakse siin konfiguratsiooni kahepoolse SSL-i kasutamiseks Eesti eID kaartidega. Siiski tuuakse järgnevalt välja punktid, mida on oluline mainida.

Kasutajapoolsete sertifikaatide filtreerimine

Vaikimisi pakutakse kasutajapoolse kahepoolse SSL sessiooni alustamisel IIS puhul kliendile välja kõik sertifikaadid, millistel on EKU omaduste all kirjas kliendi autentimine (ja loomulikult peab olema ka sertifikaadi privaatvõti). IIS-i poolt on aga kliendile võimalik ette anda loend autentimiskeskustest millised on lubatud ja seeläbi kuvatakse edaspidi klientidele vaid toetatud ahelate sertifikaadid.

Seame eesmärgiks kuvada kasutaja pool vaid sertifikaadid, mis pärinevad kindla juurserveri EE-GovCA2018 ja EEGovCA2025 ahelast.

1. Kuvatakse aktiivse IIS sertifikaadi info käsuga netsh http show sslcert 0.0.0.0:443:

   

2. Eemaldatakse sertifikaadi seos käsuga netsh http del sslcert 0.0.0.0:443:

   

3. Sertifikaat lisatakse uuesti, määrates sertifikaatide filtreerimiseks arvuti sertifikaatide kaust Client Authentication Issuers. Käsuks on netsh http add sslcert ipport=0.0.0.0:443 certhash=1e75c77c696aa4d49686bb1ef73ac3b07fdff38a appid={4dc3e181-e14b-4a21-b022-59fc669b0914} sslctlstorename=ClientAuthIssuer:

   

   Certhash ja appid väärtused saab võtta 1. sammu väljundist ülal.

4. Tuleb kontrollida, et CTL Store Name on uuel sertifikaadi väljavõttel ClientAuthIssuer:

   

   Soovi korral on võimalik vaadata ka IIS-i konfiguratsioonist, et SSL sertifikaat on uuesti korrektselt seotud 443 pordiga.

5. Lubatakse IIS serveri registrist sertifikaatide filtreerimine, lisades määrangu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList=1:

   

6. Lisatakse SK kesktaseme sertifikaat IIS serveri sertifikaatide konteinerisse Client Authentication Issuers:

   

7. Vajadusel taaskäivitatakse IIS teenus või server ja kontrollitakse soovitud lahenduse toimimist!

Kliendisertifikaatide kehtivuse kontroll OCSP teenuse vastu

OCSP teenuse abil on võimalik kasutaja sertifikaadi kehtivust kontrollida praktiliselt reaalajas. Iga kasutaja autentimisel saadab veebiserver päringu OCSP teenusele, mis tagastab sertifikaadi kehtivuse info.

ESTEID2018 ja ESTEID2025 CA alt väljastatud sertifikaatide puhul on AIA OCSP aadress juba sertifikaadis kirjas (http://aia.sk.ee/esteid2018 ja http://ocsp.eidpki.ee), nii et tegelikult midagi eraldi konfigureerima ei ole vaja. Küll aga on soovi korral võimalik kehtestada ka keskelt AIA OCSP kontroll:

Märkus: Kordan siin selguse mõttes, et ESTEID2018 / ESTEID2025 CA alt väljastatud sertifikaatidel on kehtivuskontrollina kasutusel AIA OCSP teenus aadressiga http://aia.sk.ee/esteid2018. CRL teed neis kirjeldatud ei ole.

Märkus: Windows serveri puhul pöördutakse vaikimisi OCSP põhiselt sertifikaatide kehtivuse kontrollilt tagasi CRL põhisele kontrollile, kui vahemälus olevate OCSP päringute hulk ületab 50-ne piiri. Käesoleva konfiguratsiooni puhul ei ole see tegelikult oluline, kuna CRL-i üldse ei kasutata. Muude konfiguratsioonide puhuks mainin, et seda numbrit on võimalik muuta luues registri väärtuse HKEY_LOCAL_MACHINE/Software/Policies/Microsoft/SystemCertificates/ChainEngine/Config/CryptnetCachedOcspSwitchToCrlCount ja määrates sinna uue väärtuse. Vt. ka OCSP magic count või magic number. Ehk aga lihtsamgi tee selle omaduse muutmiseks on windows policy:

Soovituslikud IIS’i sätted

SSL/TLS

IIS’i versioon 10 serveril 2022 kasutab vaikimisi kõiki TLS protokollide versioone, 1.0–1.3⁶. Vanemad SSL protokollid ei ole vaikimisi kasutusel.

Tänapäeval ei tohiks kindlasti enam kasutada TLS 1.0 ja TLS 1.1. Kahepoolse autentimise toimimiseks peab olema lubatud TLS 1.2 ja loodetavasti ajutiselt keelatud TLS 1.3 (loe täpsemalt peatükist „Kahepoolse SSL-i, sertifikaadiga autentimise nõudmine – Eelhäälestus”). Kui sertifikaadiga autentimine ei ole oluline, võib hea mõte olla lubada vaid TLS 1.3.

Rohkem infot TLS protokolli kasutamise soovituste kohta leiab RIA tellitud krüptograafiliste algoritmide elutsükli uuringust aadressil https://www.id.ee/artikkel/kruptograafiliste-algoritmide-elutsukli-uuringud-2/.

Lisaks IIS konfiguratsiooni juures vanade TLS protokollide keelamisele saab seda teha ka otse registris. TLS 1.0 ja TLS 1.1 keelamiseks tuleb registrisse lisada järgmine konfiguratsioon⁷:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\⁸:
  • TLS 1.0\Server
    • Enabled DWORD:0
    • DisabledByDefault = DWORD:1
  • TLS 1.1\Server
    • Enabled DWORD:0
    • DisabledByDefault = DWORD:1

Ja muidugi on võimalik ülaltoodud registri konfiguratsiooni levitada ka kesksete poliitikate abil.

Šifrikomplektid (Cipher suites)

Windows serveriga tuleb vaikimisi kaasa mitmeid šifrikomplekte. Kõiki neid saab vaadata näiteks PowerShell käsuga Get-TLSCipherSuite⁹.

Kindlat soovitust erinevate šifrikomplektide kasutamiseks ei ole veebisaidile esitatavaid tingimusi teadmata võimalik anda. Küll aga tundub mõistlik eemaldada loendist ebaturvalised šifrikomplektid (juhul, kui neid seal on). Enne konfiguratsiooniga jätkamist soovitame kindlasti tutvuda RIA tellitud krüptograafiliste algoritmide elutsükli uuringu soovitustega aadressil https://www.id.ee/artikkel/kruptograafiliste-algoritmide-elutsukli-uuringud-2/. Mõistlik võib olla konkreetsete šifrikomplektide lubamine.

Seega, täpsema kontrolli soovimiseks kasutatavate šifrikomplektide üle, on ilmselt parim kasutada kohalikke või keskseid poliitikaid. Kasutamaks ainult šifrikomplekte ECDHE-ECDSA-AES256-GCM-SHA384 ja ECDHE-RSA-AES256-GCM-SHA384, tuleb modifitseerida määrangut Computer Configuration/Administrative Templates/Network/SSL Configuration Settings: SSL Cipher Suite Order. Šifrikomplektid tuleb eraldada komaga.¹⁰

Eelmises punktis määratud konfiguratsioon kirjutatakse registrisse:

Vaikimisi on šifrikomplektid kirjeldatud järgmisel pildil kirjeldatud asukohas:

Muud konfigureeritavad Schannel omadused

Vaikimisi asukoht Schanneli konfigureeritavatele omadustele on registris: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. Siin on võimalik erinevaid komponente lubada või keelata, kirjutada vajadusel üle vaikimisi konfiguratsiooni määranguid.

Muud võimalused

Lisaks TLS-i ja šifrikomplektide konfigureerimisele, on palju muudki võimalik ära teha IIS-i serveri turvamiseks:

• Hoida operatsioonisüsteem ajakohasena.
• Keelata serveri info presenteerimine.
• Keelata HTTP päringud.
• Keelata failide lappamise võimalus (directory listing).
• Kasutada mitte-süsteemseid ja mitte-administraator kontosid.
• Lubada HSTS.
• …

Palume suhtuda ülaltoodusse kui näidisloendisse demonstreerimaks, mida veel saab IIS’i turvalisemaks muutmise jaoks ära teha. Põhjalikemaid soovitusi on võimalik leida paljudelt internetilehtedelt:

https://www.google.com/search?q=how+to+secure+IIS+server

1. https://www.id.ee/artikkel/paigalda-id-tarkvara/ ↩

2. Trusted root certification authorities ↩

3. Juhul, kui sertifikaadi on väljastanud mõni kesktaseme CA, siis tuleb see puudumisel lisada kesktaseme sertimiskeskuste konteinerisse. Ja kesktaseme CA sertifikaadi väljastanud juur-CA sertifikaat tuleb puudumisel lisada usaldusväärsete juursertifikaatide konteinerisse. ↩

4. Firefox teadaolevalt toetab, ent ka sellel brauseril ei ole see vaikimisi lubatud. ↩

5. SK poolt väljastatud organisatsioonide kaartide kasutuse puhul peavad kesktaseme sertifikaatide hulka olema häälestatud ka EID-SK 2016 (https://www.sk.ee/upload/files/EID-SK_2016.der.crt) sertifikaadid! ↩

6. https://docs.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-?redirectedfrom=MSDN ↩

7. Vaikimisi neid väärtuseid ei eksisteeri. ↩

8. Võimalik on konfigureerida eraldi ka kliendi osa SSL/TLS protokollide vaates. Käesolev juhend käsitleb ainult serveri poole häälestust. See ei tähenda, et kliendi osa konfigureerimine ei ole soovitatav, see sõltub alati konkreetsest situatsioonist. ↩

9. https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel ↩

10. Märgitagu siinkohal, et nende konkreetsete määrangutega TLS 1.3 ei toimi! Pigem võib nende määrangute kasutamine olla mõttekas juhul, kui TLS 1.3-e ei soovita kasutada, kasvõi näiteks sertifikaadiga autentimise lubamise puhul. ↩