Jun 19, 2012 at 3:14 PM
Edited Jun 19, 2012 at 3:14 PM
The workaround to not have to rebuilt the package for each DNN installation, is to have "fixed" definitions on the "Certificates" section. If we don't use SSL for a DNN install, the RDP thumbprint will be used to avoid Windows Azure deployment
In this link you can download a package file that uses SSL. Actually there is no UI yet on the Wizard to configure these parameters, so here is a description
of how to use it:
1) Manually replace in the file "DNNAzureSingleAndSmall_RDP_SSL.cscfg" the tokens "@@XXX@@" for those ones that are in your actual deployment.
2) Manually upload your SSL certificate to Windows Azure through the management portal, associating it to the hosted service. The format of this certificate must be a PFX file, and IMPORTANT: make sure that the PFX file includes the private key, and includes
all the intermediate certificates from the CA that issued it. If your PFX file does not include the intermediate CA certificates, manually upload them (normally it's more difficult to have these certificates in PFX format that include them in the SSL certificate).
3) Attention to the new SSL settings in the .cscfg file:
<Setting name="SSL.CertificateThumbprint" value="" /> <!-- Type the thumbprint of the SSL certificate -->
<Setting name="SSL.HostHeader" value="" /> <!-- Host header to bind. Leave it in blank at this moment -->
<Setting name="SSL.Port" value="443" /> <!-- Port to bind -->
4) Also check these new certificate settings in the "Certificates" section. Replace the thumbprints using:
SSL = SSL certificate thumbprint
SSL.CA1 = Thumbprint of an intermediate CA
SSL.CA2 = Thumbprint of an intermediate CA
Note that if your certificate only have one intermmediate certificate for CA, you can use the thumbprint used for RDP.
<Certificate name="SSL" thumbprint="@@RDPTHUMBPRINT@@" thumbprintAlgorithm="sha1" />
<Certificate name="SSL.CA1" thumbprint="@@RDPTHUMBPRINT@@" thumbprintAlgorithm="sha1" />
<Certificate name="SSL.CA2" thumbprint="@@RDPTHUMBPRINT@@" thumbprintAlgorithm="sha1" />
Essentially, the last section means the certificates that WA will install in your instance when deployed, obtaining them from the certificate store associated to the hosted service. Actually HTTPS was not working in your installation, because of these certificates
were not being installed on deployment -and the previous accelerator package was not binding anything to the SSL port.
Final note: if your certificate have more than 2 CAs, this package won't work because the trust chain won't be completely configured. I will build a package with at least 5 CAs, that I think that is sufficient in most of the cases.
Hope this helps,