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.