Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 1/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.
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 2/16
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!
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 3/16
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:
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 4/16
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:
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 5/16
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.
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 6/16
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
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 7/16
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“:
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 8/16
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.
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 9/16
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
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 10/16
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:
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 11/16
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:
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 12/16
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.
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 13/16
• 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
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 14/16
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.
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 15/16
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.
MS IIS EID card support Administrator guidance
RIA EID Guidances https://www.ria.ee Page 16/16
• 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.