Configuring IIS web server to support ID-card

CONFIGURATION OF ID-CARD SUPPORT
FOR IIS WEB SERVER
Instructions for user authentication on IIS web server.
VERSION INFORMATION
Date
Version
Changes
Manual updated to the Windows Server 2016 level, added KLASS3-SK 2016
certificate support.
Removed chapter "ABOUT IIS SERVERS AND CLIENT'S CERTIFICATE CHAIN".
Removed chapter "ID-CARD CERTIFICATE VALIDITY CHECK".
04.2017
1704
Added note on the possibility to use free OCSP service.
Added note on the configuration of sub-certifier EID-SK 2016.
Changed version logic. For new logic the version number XXXX is derived from
year/month (yy:mm).
09.2016
6.3
Added information on the configuration of sub-certifier EID-SK 2011 issued on 18
March 2011.
08.2016
6.2
Removed installation instructions for Juur-SK, ESTEID-SK 2007 and KLASS3-SK
2010 (Juur-SK) due to expiration of root certificate (Juur-SK) on 26 August 2016.
01.2016
6.1
Added information on the configuration of sub-certifier ESTEID-SK 2015 that was
introduced on 17 December 2015.
Added configuration information to instructions on SK's intermediate certificates
11.2015
6.0
ESTEID-SK 2007 and ESTEID-SK 2011.
Fixed links related to test-OCSP.
01.2012
5.0
Removed sub-certifier ESTEID-SK configuration instructions because ESTEID-SK
CA expired on 13 January 2012
06.2011
1.0
First public version
INTRODUCTION
These instructions describe how to execute user authentication support on Microsoft IIS web services using
certificates issued by SK (ID-card, residence permit card, digi-ID and e-residency digi-ID). The instructions have
been created using Windows Server 2016 platform. The sample instructions support the certificates issued
from "EE Certification Centre Root CA" chain of the Certification Centre.
Various authentication methods may be applied when using IIS. This document addresses the implementation
of the certificate requirement for IIS anonymous authentication, i.e. that after certificate validity verification
the user will be granted access to the website with previously defined user's (IUSR) permissions.
GENERAL REQUIRED CONFIGURATION OF IIS SERVER
IIS server must be configured to require a certificate from the user. IIS server permits any certificate to be used
to communicate with it, as long as they are issued from the same root certificate chains that it trusts. However,
IIS server must be able to create the whole certificate chain from the user certificate to the root certificate –
this means that in addition to having root level certificates on IIS server, the existence of intermediate
certificates is also necessary. In order to implement the certificate requirement and permit the use of
certificates issued from SK chains:
1) Necessary certificates must be properly imported/published:
a. To the trusted certificate store:
i. "EE Certification Centre Root CA"
(https://www.sk.ee/upload/files/EE_Certification_Centre_Root_CA.der.crt)
b. To the intermediate certificate store1:
i. ESTEID-SK 2011 (https://www.sk.ee/upload/files/ESTEID-SK_2011.der.crt)
ii. ESTEID-SK 2015 (https://www.sk.ee/upload/files/ESTEID-SK_2015.der.crt)
iii. If the IIS server SSL certificate is an SK certificate that was issued from level "KLASS3SK
2016"2,
then
also
certificate
"KLASS3-SK
2016"
(https://www.sk.ee/upload/files/KLASS3-SK_2016_EECCRCA_SHA384.der.crt).
2) An SSL certificate must be defined on IIS server - in our example, a certificate issued by SK is used that
is issued from "KLASS-SK 2016" level3, however it may easily also be a web server certificate issued
from another chain:
Figure 1 - IIS server certificate
1
when using organisation cards issued by SK, the intermediate certificates must also include the configuration
of EID-SK 2011 (https://sk.ee/upload/files/EID-SK_2011.der.crt) EID-SK 2016
(https://www.sk.ee/upload/files/EID-SK_2016.der.crt) certificates!
2 "Klass3-SK 2016" certificate is valid since 1 June 2017. Until then, web server certificates will be issued from
the "Klass3-SK 2010" level https://www.sk.ee/upload/files/KLASS3-SK_2010_EECCRCA_SHA384.der.crt).
3
That, in turn, is issued by "EE Certification Centre ROOT CA".
3) The desired website must have enabled SSL port (443 by default) and this must be bound to the
desired certificate:
Figure 2 - the website has port 443 enabled and the used certificate is SKDEV2.id.demo
4) The use of SSL protocol and client certificates must be required from the SSL settings of the website:
Figure 3 - SSL and certificate requirement
Note! Additional information on the web certificates is available at http://www.sk.ee/teenused/veebiserverisertifikaadid.
The created configuration requires access to the website through port 443 and a user certificate. When
addressing the website, it is permitted to select a certificate accepted by the server:
Figure 4 - prompt for a certificate when addressing a website, Google Chrome
After the PIN number is entered, certificate validity is verified by the web server and, if successful, the user will
be granted access to the website.
Alternatively, the IIS certificate requirement (Require) may be replaced with a simple certificate acceptance
(Accept) by IIS server – this allows accessing a server with a username and a password in addition to the
certificate.
AUTHENTICATION
Only anonymous authentication is permitted in our example:
Figure 5 - anonymous authentication, user gains access to site with IUSR permissions
USER CERTIFICATE VALIDITY CONFIRMATION
The validity of a web application visitor's authentication certificate must be verified against the OCSP service
(validity confirmation service) to ascertain that the user attempting to access the website has valid certificates
(OCSP status GOOD).
For example, in case of a stolen ID-card and PIN numbers, certificates should be suspended at the ID-card
holder's initiative and in general in case of an ID-card with invalid certificates for any reason (OCSP status
REVOKED or UNKNOWN) a user should not be authenticated to the website.
OCSP may be carried out on the web application level. A sample application is available at
http://www.id.ee/index.php?id=30368 for making OCSP requests from PHP applications, in .Net applications
the client certificate should be read from the variable Request.ClientCertificate and then any library available
on the web may be used to make OCSP requests, such as http://www.bouncycastle.org/csharp/
During application testing we recommend using SK Test-OCSP service at http://demo.sk.ee/ocsp, the
authentication certificate must previously be registered in the test environment in order for Test-OCSP to be
able to say something about the certificate validity: https://demo.sk.ee/upload_cert/
Live-OCSP service that provides real-time validity information on certificates issued by SK is located at
http://ocsp.sk.ee, but a contract should be concluded with SK to use it. Additional information on the service
description and ordering is available at http://www.sk.ee/teenused/kehtivuskinnituse-teenus
User certificate validity may also be verified using CRLs or against a free OCSP, but it is recommended to do it
against a paid OCSP service, which ensures high availability of the provided service.
Download PDF