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).

  • 2
    "Chrome displays full page security error" That's not enough information to be answerable. It looks it's the gist of your question (well it should be), despite you've buried it quite deeply. – kubanczyk May 11 '18 at 10:36
  • 1
    Chrome does always require SAN for the domain. – Gerrit May 11 '18 at 11:27
  • @kubanczyk I took a closer look and now I see that Chrome displays error code of NET::ERR_CERT_COMMON_NAME_INVALID, caused by missing SAN I believe. I will reissue the certificate and test. However I intended the question to be more general than just the error reported by Chrome - not "Why does Chrome show this error message?" but rather "How should certificates be issued in general so browsers/servers accept them?". – Maciek May 11 '18 at 12:07
  • I reissued the server certificate and set the proper SAN. Now Subject CN and one of SAN entries are effectively identical, and Chrome and Opera do not complain anymore. So seems that missing SAN was the problem with Chrome. – Maciek May 14 '18 at 9:43

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:

  • Actual domain is not going to be .local, but rather something else, like .lan or .office or something. However I was not aware that .local has special meaning, thanks! – Maciek May 11 '18 at 12:13
  • Thank you for this nice answer, and all references! Some things I was aware of (need for CRL/OCSP), but some are very nice hints I did not think about (behavior specific to the processes hosted in the browser). I have some follow up questions, but I will ask them in separate topics if I can't find answers by myself. Thanks! – Maciek May 14 '18 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.