Mutual SSL authentication and requirements for certificates

Question

For our internal tests I need to set up the mutual SSL authentication between our IIS server (it hosts two applications: ASP.NET web GUI and a web service) and clients (accessing the server in two possible ways: web GUI with a browser and web service with a client created with WinForms). When tests are finished and results are evaluated, I will have to give some pointers to our customer how to set it up and configure on their environment - a closed, corporate environment, reachable by non-public URLs via VPN.

I am quite familiar with PKI, keys and certificates in general, I just do not have much experience with PKI in context of HTTPS. With some available tools, mostly XCA, I managed to create my root CA certificate, server certificate and a bunch of client certificates; I installed them in IIS and in client stores, and things work quite smoothly, but there are some issues and questions:

• What are (extended) key usage values required for a server certificate? In my test cert, I got Digital Signature, Non Repudiation, Key Encipherment and extended TLS Web Server Authentication - am I missing any? Are all of these required?
• The same question about client certificates: what key usages are required? My test certificates have Digital Signature, Key Encipherment, Data Encipherment and extended TLS Web Client Authentication - am I missing any? Are all of these required?
• Are there any other special features that a client certificate should have?
• Server certificate should have its name listed in a list of SANs as a DNS entry (or IP, if accessed by IP address, right?). But what about Subject's CN field of its Distinguished Name? should it have any specific form? Should be empty? Can non-public addresses, like, for example, mytestenv.mycompany.lan be used as a SAN? Currently in my test server cert I have only a Subject CN set, and no SAN DNS entry, and I believe I need to add it, am I right?
• Are there any steps (other than adding CA cert to trusted CAs in browser or Windows store) I need to take to prevent browsers from displaying full-page security warning about site not being secure? I think I can live without 'green lock' or with some warning in an address bar or something, but for example Chrome displays full page security error and does not show the web page until I configure a security exception for the server. How can I prevent that? May missing SAN be the cause? IE and Firefox display the page.
• Do things like DV/OV/EV, Certificate Transparency, "HTTPS apocalypse" incoming for browsers, or maybe something else, affect my (and possibly customer's) setup in any way? Do I need to take a particular care of these?

If possible, I would be interested in both general remarks, and in requirements of specific servers (especially IIS) and browsers (in customer's infrastructure these are going to be mostly IE 11+ and Edge).

Answer 1

Key usage

For TLS you need Key Encipherment and Digital Signature as well as the applicable TLS Web Server/Client Authentication extended usage. Non Repudation is not used. Key Agreement could theoretically be used for ECDH as opposed to ECDHE. See https://security.stackexchange.com/a/24107

Certificate Transparency.

Google is pushing this with their considerable clout. One important thing to consider when submitting certificates to transparency logs, is that they are in fact a publication of domain names (or wildcard). I have noticed queries to a webserver right after getting a letsencrypt certificate, and in theory this can be even before your ssl certificate is actually installed, because the transparency log has a pre publication.

See: Scott Helme blog

April Chrome update:

From: https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/wHILiYf31DE

Since January 2015, Chrome has required that Extended Validation (EV) certificates be CT-compliant in order to receive EV status. In April 2018, this requirement will be extended to all newly-issued publicly-trusted certificates - DV, OV, and EV - and certificates failing to comply with this policy will not be recognized as trusted when evaluated by Chrome. Certificates issued from locally-trusted or enterprise CAs that are added by users or administrators are not subject to this requirement.

SAN with local names

No issues that I know of. Although .local is an especially nasty TLD, because it is used with multicast DNS.

Other requirements

For any mature system there is the need for CRL and OCSP servers. Some subprocesses can be even more demanding then the browser itself. Take for example Java plugin in IE11. If a webstart application or applet has an unreachable CRL or OCSP server in the hierarchy, the browser frame can remain completely blank for minutes. Also if a Apache webserver uses OCSP stapling, then the OCSP server had better respond when the webserver itself calls, otherwise unfortunately with Apache all clients will display errors until the server has the responses stapled again.

Authority Key ID. Use this feature to make it possible to recover from withdrawing intermediates certificates either by error or because of compromise.

CAA records. Public CA's are required to check this when issuing certificates. See https://scotthelme.co.uk/certificate-authority-authorization/

Further references:

• https://www.ietf.org/rfc/rfc5280.txt
• https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates
• http://www.zytrax.com/tech/survival/ssl.html