IIS URL Rewrite/SSL certificates

I will be using DigiCert Multi-Domain certificates for the following:

  www.example.com
  example.com
  sub1.example.com
  www.sub1.example.com
  sub2.example.com
  www.sub2.example.com

     etc...

I am using IIS URL Rewrite to remove www. from all domains, which gives me:

  example.com
  sub1.example.com
  sub2.example.com

I am also using URL Rewrite to route all http:// to https://.

My questions:

1. Do I need www. domain certificates since I am rerouting to the stripped down version of the URL?
2. Are the www. prefixed certificates necessary to negotiate the initial SSL connection?

If possible, I would like to eliminate all www. certs.

Edited

For completeness, I have added the two redirections I am using.

<rewrite>
  <rules>
    <rule name="Remove www" stopProcessing="true">
      <match url="(.*)" ignoreCase="true" />
      <conditions logicalGrouping="MatchAll">
        <add input="{HTTP_HOST}" pattern="^www\.(.+)$" />
      </conditions>
      <action type="Redirect" url="https://{C:1}/{R:0}" appendQueryString="true" redirectType="Permanent" />
    </rule>
    <rule name="Redirect to http" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
      <match url="*" negate="false" />
      <conditions logicalGrouping="MatchAny">
        <add input="{HTTPS}" pattern="off" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" />
    </rule>
  </rules>
</rewrite>

Thanks...

Update: Undesirable Side Effects

After doing a lot of testing, I have found some undesirable side effects with removing the www. from URLs. Under certain conditions, a user will see a security warning about the site NOT being secure, which is really bad from our perspective.

Possible User Entered URLs:

example.com, www.example.com, http:// or https:// with example.com or www.example.com

Desired Rewrite URL:

https:// + example.com

Differences between Browsers

The https:// + www.example.com/ URL is NOT rewritten to the desired URL on IE, Edge, Safari, and Firefox, BUT is rewritten with Chrome. After thinking about this for a while, I am not sure why Chrome allows the HTTPS rewrite, since a hard coded HTTPS URL was input.

Chrome routes https:// + www.example.com/ to https:// + example.com. No cert failures are displayed to the user.

IE Cache Corruption?

After entering the URL https:// + www.example.com on IE, it seems to corrupt the history cache.

If you enter www.example.com after entering the previous URL, the browser routes to https:// + www.example.com/. This yields a BAD cert message, which is not good.

IE can be closed and reopened and the anomaly continues, if your re-enter www.mydomain.com.

If I manually clear the cache of the bad https:// + www.example.com URL and then enter www.example.com, IE routes to https:// + example.com, which is the desired result.

Safari Temp Cache Corruption?

I was able to demonstrate a similar failure on MAC Safari for the same test conditions that I used for IE, but Safari recovered after navigating to other URLs and back OR closing/reopening the browser.

Conclusion for our Use Model

Eliminating www. is not a good option.

The TLS session is set-up before any processing - including rewrites. Therefore to avoid browser errors you should ensure that your certificate contains Subject Alternate Name entries for all DNS names that you expect your clients to enter in their browsers. That includes www ones.

The only exception would be in the case where you redirect from http://www.example.com (no TLS) to https://example.com (TLS). In this case the rewrite would happen over http and consequently wouldn't involve TLS and certificates.