D
Dapperville Inn
I have deferred this part of the IT Admin wheelhouse for far too long and am afraid it's become a stumbling block for me at this point in my experience so I'm humbling myself and diving headlong into Web Administration, specifically via IIS (v. 8.5 default with srvr 2012 R2).
So as I'm reading copious amounts of information regarding IIS, it's hard to separate the facts from fiction (might be a result of assumptions on my part) in the litany of public resources.
Some things I have taken for granted, I have discovered not to be true; e.g. the web.config file--I have seen it before, I have even tweaked working copies.
However, as I have delved into provisioning a new website for services like (Network Location Services, (M)SCEP, etc.), I have found that creating a new site via IIS Admin (inetmgr.exe) does not automatically create the expected web.config file, which I previously understood to be a sort of default. Chalk it up to ignorance and mismanaged expectations. I should declare that I only checked the configured "Content Directory" and its specified physical path, since I understand that to be the root path for a given website, to use web-admin jargon. If I should have looked elsewhere; I understand a root web.config file exists but expect that governs its appropriate settings at the "server-level" and the per-site web.config file will be placed elsewhere, presumably in the 'root' as demonstrated earlier.
So my first question is,
I am intending to be use said document for its ability to host per-site binding-configurations. Please bear that in mind when responding.
Also, I am having a heck of a time with SSL bindings as I have tried to provision these HTTP components from a singular IIS instance??, i.e. a single server. I am hoping to accomplish this, lab environment, to simplify administration for training.
I have come across guidance for a Central Cert Store so that is the direction I'm headed; since previously trying to host multiple HTTP service endpoints and allocating appropriate SSL bindings (again, prior to Central Cert Store) has resulted in IIS automatically using a singular cert for all sites' SSL bindings, breaking HTTPS protocol.
So, another thing I have noticed is that when SSL is configured (a certificate added to https binding for a site).
To elaborate, let's say an example host site of HTTPS://NLS.CORP.CONTOSO.COM. If I specified a literal subject name value of "CN=NLS,DC=CORP,DC=CONTOSO,DC=COM," would that work? Or would I need to squeeze in the entire FQDN, treating the FQDN and its various components as a singular value for the sake of HTTPS functionality--i.e. specifying "nls.corp.contoso.com" entirely for the CN in the subject of the requested certificate? I think I have been misguided (by my own intuition) into thinking that the x.500 specification would be king while specifying DNS-typed values in the subject-alternative-name extension would be satisfactory but I get hit for mismatched host names when trying to access the sites that way. I have read the "CN needs to match the subject name exactly" but then the articles don't really elaborate or illustrate examples. Without accompanying examples, it seems kind of ambiguous and I have yet to come across anything that really puts a nail in the coffin for the debate.
Please enlighten me.
I look forward to learning from the seasoned pros.
Thanks for your time, in advance!
Respectfully,
Dapp
Continue reading...
So as I'm reading copious amounts of information regarding IIS, it's hard to separate the facts from fiction (might be a result of assumptions on my part) in the litany of public resources.
Some things I have taken for granted, I have discovered not to be true; e.g. the web.config file--I have seen it before, I have even tweaked working copies.
However, as I have delved into provisioning a new website for services like (Network Location Services, (M)SCEP, etc.), I have found that creating a new site via IIS Admin (inetmgr.exe) does not automatically create the expected web.config file, which I previously understood to be a sort of default. Chalk it up to ignorance and mismanaged expectations. I should declare that I only checked the configured "Content Directory" and its specified physical path, since I understand that to be the root path for a given website, to use web-admin jargon. If I should have looked elsewhere; I understand a root web.config file exists but expect that governs its appropriate settings at the "server-level" and the per-site web.config file will be placed elsewhere, presumably in the 'root' as demonstrated earlier.
So my first question is,
- what is the deal with web.config and how do I go about generating/creating a valid copy for use?
I am intending to be use said document for its ability to host per-site binding-configurations. Please bear that in mind when responding.
Also, I am having a heck of a time with SSL bindings as I have tried to provision these HTTP components from a singular IIS instance??, i.e. a single server. I am hoping to accomplish this, lab environment, to simplify administration for training.
I have come across guidance for a Central Cert Store so that is the direction I'm headed; since previously trying to host multiple HTTP service endpoints and allocating appropriate SSL bindings (again, prior to Central Cert Store) has resulted in IIS automatically using a singular cert for all sites' SSL bindings, breaking HTTPS protocol.
- If that seems misguided, please advise.
So, another thing I have noticed is that when SSL is configured (a certificate added to https binding for a site).
- The CN of the certificate subject-value, does it need to be treated as a singular value even if the value would be separated into its appropriate components of an X.500-compliant name?
To elaborate, let's say an example host site of HTTPS://NLS.CORP.CONTOSO.COM. If I specified a literal subject name value of "CN=NLS,DC=CORP,DC=CONTOSO,DC=COM," would that work? Or would I need to squeeze in the entire FQDN, treating the FQDN and its various components as a singular value for the sake of HTTPS functionality--i.e. specifying "nls.corp.contoso.com" entirely for the CN in the subject of the requested certificate? I think I have been misguided (by my own intuition) into thinking that the x.500 specification would be king while specifying DNS-typed values in the subject-alternative-name extension would be satisfactory but I get hit for mismatched host names when trying to access the sites that way. I have read the "CN needs to match the subject name exactly" but then the articles don't really elaborate or illustrate examples. Without accompanying examples, it seems kind of ambiguous and I have yet to come across anything that really puts a nail in the coffin for the debate.
Please enlighten me.
I look forward to learning from the seasoned pros.
Thanks for your time, in advance!
Respectfully,
Dapp
Continue reading...