configuring iis to support estonian digital id card …

MS IIS EID card support Administrator guidance

RIA EID Guidances https://www.ria.ee /16

CONFIGURING IIS TO SUPPORT

ESTONIAN DIGITAL ID CARD FOR

AUTHENTICATION

Document information

Date of creation 21.01.2019

Receivers RIA

Author Urmas Vanem, OctoX

Version 19.12/1

Version information

Date Version Changes/Notices

21.01.2019 19.01/1 Public version, based on 18.12 software

12.02.2019 19.02/1 Added OCSP options. Changed by Urmas Vanem.

01.10.2019 19.10/1 Added information about Windows server (IIS) patches statuses and future availability by versions. See paragraph 6 in introduction. Changed by Urmas Vanem.

18.10.2019 19.10/2 Added information about Windows Server 2016 update KB4516061, which solves Chrome-IIS problem. Changed by Urmas Vanem.

08.11.2019 19.11/1 Added information about Windows Server 2019 update KB4520062, which solves Chrome-IIS problem. Changed by Urmas Vanem.

14.11.2019 19.11/2 Added information about Windows Server 1903 (SAC) update KB4524570, which solves Chrome-IIS problem. Changed by Urmas Vanem.

12.12.2019 19.12/1 Added recommendations for securing IIS. Changed by Urmas Vanem.



Guidance, how to configure IIS to support Estonian digital ID card for authentication.

Introduction In this guidance we describe how to configure Microsoft IIS web services to require two-way SSL. On

server side we can use any certificate with server authentication EKU, trusted by clients. On client side

we use any of Estonian digital ID card (ID card, residence card, digital ID card or E-resident’s card).

While creating this guidance we used Windows Server 2019 and Windows 10 operating systems. On

client side we support certificates issued from „EE Certification Centre Root CA“ and EE-GovCA2018

certificate authorities. To recognize user smart card certificate, we also need ID card software on both

server and client side1. Server certificate is issued from OctoX test CA.

We can use different authentication methods in IIS. In this guidance we configure IIS in simplest

possible way and use only anonymous authentication – after authentication users can access website

as dedicated (IUSR) user.

Currently we tested the configuration with following browsers (latest versions):

1) Microsoft Edge

2) Microsoft Internet Explorer

3) Mozilla Firefox

4) Google Chrome

Microsoft IIS and Google Chrome combination will work fine with new ID card (EE-GovCA2018 chain,

IDEMIA), when following update is installed on Windows server:

• Version 2016 (LTSC) works fine with cumulative update KB4516061!

• Version 2016 (LTSC) works fine with cumulative update KB4520062!

• Version 1903 (SAC) works fine with cumulative update KB4524570!2

Server versions 2012 and 2012 R2 will not be fixed because are out of mainstream support period.

IIS server required configuration IIS server need to be configured to use two-way SSL, so user need certificate to access web services.

By default, IIS allows all user certificates where client authentication EKU exists. Full chain on client

certificates must also be defined on IIS server, we need to import bot root and intermediate certificates

from two chains. In our situation we need to add following certificate to IIS server certificate store:

1) Trusted Root Certification Authorities:

1 https://installer.id.ee/?lang=est 2 For server version 1909 (SAC) the same update is available, if our problem with IIS/Chrome authentication is not solved there by default!

https://www.catalog.update.microsoft.com/Search.aspx?q=KB4516061

https://www.catalog.update.microsoft.com/Search.aspx?q=KB4520062

https://www.catalog.update.microsoft.com/Search.aspx?q=kb4524570

https://installer.id.ee/?lang=est



a. „EE Certification Centre Root CA“

(https://sk.ee/upload/files/EE_Certification_Centre_Root_CA.der.crt)

b. EE-GovCA2018 (http://c.sk.ee/EE-GovCA2018.der.crt)

2) Intermediate Certification Authorities:

a. „ESTEID-SK 2011“ (https://sk.ee/upload/files/ESTEID-SK_2011.der.crt)

b. „ESTEID-SK 2015“ (https://sk.ee/upload/files/ESTEID-SK_2015.der.crt )

c. ESTEID2018 (http://c.sk.ee/esteid2018.der.crt )

In addition, IIS server needs its own certificate. Certificate used by IIS must have server authentication

option described in EKU. Clients (and IIS server of course) must trust the certificate. In our sample

environment we use certificate issued from OctoX test environment:

Picture 1 - IIS certificate

Certificate name (issued to) does not refer to server “real” address/name. Server’s address is described

under SAN attribute as DNS name and it is id2.octox.eu. Server trusts issuer, “OctoX II”.

In our website HTTPS (port 443) must be enabled and related with our server certificate:

https://sk.ee/upload/files/EE_Certification_Centre_Root_CA.der.crt

http://c.sk.ee/EE-GovCA2018.der.crt

https://sk.ee/upload/files/ESTEID-SK_2011.der.crt

https://sk.ee/upload/files/ESTEID-SK_2015.der.crt

http://c.sk.ee/esteid2018.der.crt



Picture 2 - website uses port 443 with certificate from test environment (id2.octox.eu)

Under SSL options we require two-way SSL:

Picture 3 - SSL and certificate requirement

Described configuration requires access to website over port 443 and client certificate. While

connection to server over https you’ll will be asked for certificate:



Picture 4 - Firefox asks certificate

After entering OK and PIN certificate revocation will be controlled by IIS server and if it is ok, user can

access website.

Picture 5 - PIN windows

Picture 6 - auhentication succeeded

As alternative we can use certificate acceptance instead on requiring it. In this case we can access

websites also with username or password or without authentication at all.



Authentication In our configuration we use only anonymous authentication:

Picture 7 - anonymous authenticaion, user can access website as user IUSR

Filtering certificate list on client side By default, all personal certificates with private key and user authentication EKU on client side are

listed with IIS. But it is possible to teach IIS to send clients list of acceptable certificate authorities – in

this case browser shows only supported certificates to user.

How to configure certificate filtering for client side in IIS Our goal is to support only certificates issued from chains under root CAs’ EE-GOV-CA2018 and “EE

Certification Centre Root CA”.

1) After configuring IIS to use SSL-i we can document default configuration with command “netsh

http show sslcert 0.0.0.0:443”:

Picture 8 - default https certificate options

2) Now, lets’ remove certificate binding with command “netsh http del sslcert 0.0.0.0:443”:

Picture 9 - unbind certificate



3) Now we add certificate again and order it user store „Client Authentication Issuers“ as list for

acceptable certification authorities for clients. Command is „netsh http add sslcert

ipport=0.0.0.0:443 certhash=1e75c77c696aa4d49686bb1ef73ac3b07fdff38a

appid={4dc3e181-e14b-4a21-b022-59fc669b0914} sslctlstorename=ClientAuthIssuer

Picture 10 - binding certificate with new option

Certhash and appid values can we take from first documentation step, see „Picture 8 - default https

certificate options“.

4) Now we can check does ClientAuthIssuer value exists“ after CTL Store Name”:

Picture 11 - updated output

We can also check IIS configuration to be sure SSL certificate is correctly binded to port 443.

5) No we must enable certificate filtering option in IIS server registry by adding value

“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANN

EL\SendTrustedIssuerList=1“:



Picture 12 - enabling certificate client side filtering in IIS server registry

6) To support only specific CAs’ on IIS side, we add now intermediate CAs’ to certificates

container „Client Authentication Issuers“:

Picture 13 - we trust only 2 intemediate CAs'

7) If necessary, we restart IIS service or server and check does it all works as needed.

Possible additional configurations The purpose of this document is not to give exact guidance how to configure or secure web sites. But

we want to introduce useful configurations for using two-way SSL with Estonian EID cards. In following

chapters, we point on possibilities we think are important.



Checking revocation status of client certificates against OCSP service Using OCSP service we can check revocation status of client certificates practically in real time. In every

client authentication attempt web server sends query to OCSP service, which responds with client

certificate revocation status.

Guaranteed SK OCSP service Guaranteed SK OCSP service works on address http://ocsp.sk.ee and is the same for all certificates

issued from Estonian EID chains. For using guaranteed SK OCSP service client must have specific

agreement with SK – after the conclusion of the contract SK grants access to the service based on IP

address or certificate.3

Configuration For configuring guaranteed OCSP service we need to modify intermediate certificate options on web

server. Web server keeps intermediate certificates on “intermediate certificates” container.

Picture 14 - intermediate certificates in IIS server

For changing OCSP options for intermediate certificates, we must open certificate, select details, click

“Edit Properties…” and select page OCSP. Add OCSP URL http://ocsk.sk.ee to the list.

3 https://www.sk.ee/upload/files/General_Terms_of_Subscriber_Agreement_4_0.pdf

http://ocsp.sk.ee/

http://ocsk.sk.ee/

https://www.sk.ee/upload/files/General_Terms_of_Subscriber_Agreement_4_0.pdf



Picture 15 - specifying OCSP service location for all SK intermediate certificates

On the picture above we configure IIS server to check revocation status of client certificates issued by

ESTEID2018 CA against SK OCSP service http://ocsp.sk.ee. Probably we want to use the same behavior

for client certificates issued by „ESTEID-SK 2015“ CA, so we need to configure certificate “ESTEID-SK

2015” in the same way. If we want to turn off CRL based control on “old” 2015 cards, we can choose

option „Disable Certificate Revocation Lists (CRL) (not recommended)“. New cards do not use CRL-s by

default anyway.

AIA-OCSP service In addition to guaranteed OCSP service SK offers also free AIA-OCSP service with less functionality and

availability. It also acts little bit differently – aged certificates get response “GOOD” with AIA-OCSP. For

certificates issued by “ESTEID2018 CA” AIA-OCSP service location (http://aia.sk.ee/esteid2018) is

already included in certificate, so we do not need to change anything for those certificates. We can

configure our server to check revocation status of “old” 2015 certificates by adding AIA-OCSP address

http://aia.sk.ee/esteid2015 to intermediate certificate:

http://ocsp.sk.ee/

http://aia.sk.ee/esteid2018




Picture 16 – configuring „old“ 2015 certificate on IIS server

Notes • Certificates issued by “ESTEID2018 CA” has free OCSP path http://aia.sk.ee/esteid2018

described in certificate. CRL is not described for those certificates.

• Certificates issued by “ESTEID-SK 2015” has CRL address

http://www.sk.ee/crls/esteid/esteid2015.crl described in certificate. OCSP path is not

described for those certificates.

• Windows server by default changes from OCSP based revocation check to CRL based

revocation checking after 50 OCSP queries. We can change this behavior by changing registry

value of registry key

HKEY_LOCAL_MACHINE/Software/Policies/Microsoft/SystemCertificates/ChainEngine/Config

/CryptnetCachedOcspSwitchToCrlCount. For more information take a look at OCSP magic

count or magic number. We can also change the behavior with windows policy:


http://www.sk.ee/crls/esteid/esteid2015.crl



Picture 17 - changing OCSP magic count

Recommended security settings for IIS

SSL/TLS IIS version 10 is using TLS protocol versions 1.0, 1,1 and 1.2 by default4. Older SSL versions are disabled.

In our days there is probably no need to use SSL/TLS protocols with version lower than TLS 1.2

anymore. TLS 1.2 should be lowest version; it is widely used, very stable and old! Unfortunately, TLS

1.3 cannot be enabled in Windows Server because it is not supported by Microsoft yet (in 12.12.2019).

If we want to disable TLS versions 1.0 and 1.1, we must configure following registry keys with following

values5:

4 https://docs.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-?redirectedfrom=MSDN. 5 These entries do not exist in the registry by default.

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

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



• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHA

NNEL\Protocols\67:

o TLS 1.0\Server

▪ Enabled 0

o TLS 1.1\Server

▪ Enabled 0

Picture 18 – disabling TLS 1.0 and 1.1 for server part in registry

Of course, It is also possible to deploy TLS/SSL versions settings through group policy by deploying

registry settings.

Cipher suites There are many different TLS 1.2 cipher suites available with Windows Server8. We can list available

cipher suites in with PowerShell command Get-TLSCipherSuite9.

By default, this configuration can be good enough with latest versions of Windows Server; it does not

contain non-secure cipher suites. There are some published cipher suites marked as WEAK, but

probably we need some of those ciphers to support older clients.

It is impossible to give exact recommendation for configuring cipher suites because different

environments have different requirements. And requirements and possibilities are changing in time.

The only recommendation we can give here is to remove non-secure ciphers from list if any exists.

But if we want to configure cipher suites for any reason, the best way is to do it is probably using group

policy. To configure cipher suites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as only ones in our configuration, we must modify

policy setting “Computer Configuration/Administrative Templates/Network/SSL Configuration

Settings: SSL Cipher Suite Order”. Cipher suites must be separated with comma.

6 We know there are also parameter disabledbydefault, but it seems to be enough to configure parameter Enabled only to disable unwanted SSL/TLS versions. 7 It is also possible to configure client part for SSL/TLS versions, but currently we are talking about server configuration. It does not mean, that configuring client part is not recommended, it just depends. 8 We handle only TLS 1.2 ciphers in this chapter, because lower protocols should be disabled and TLS 1.3 is not supported yet. 9 https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel

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



Picture 19 - modifying cipher suites with group policy

Assigned configuration can be found from registry location presented on the following picture:

Picture 20 – applied policy settings

Default configuration settings can be found from registry location presented on the following picture:

Picture 21 - cipher suites default configuration

Please do not take sample above as recommendation. It is just an example! Configure cipher suites

only when you are sure what you are doing. Goals can be: disabling non-secure cipher suites or

optimizing configuration by moving faster secure ciphers to the top of the list or any other.



More configurable Schannel settings Default location for all Schannel settings is

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. It is possible to

enable or disable different Schannel components here, overwrite default configuration.

Picture 22 - Schannel configurable options

Additional possibilities In addition to TLS and cipher suite configuration there are many other things we can do to secure our

server:

• Keep operating system up to date.

• Disable presenting server information.

• Disable HTTP requests.

• Disable directory listing.



• Run under separate non-system and non-administrator accounts.

• Enable HSTS.

• …

Please take the list above as short demo recommendations list. Of course, it makes sense to follow the

recommendations, but there can be much more you can do to secure your server:

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

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

configuring iis to support estonian digital id card …

Documents