Getting an Azure Web Role to work with SSL, and then with ACS with real SSL certificate
It took me a week and some hosting provider change to get my Azure stuff working the way I wanted it to work. I am going to try and mention everything here so it is easy for the next person.
Just note, whatever I have not mentioned, there are plenty of examples online, and they work, but you need the below thing in addition to those articles to really get it to work.
1. Discountasp.net sucks. Because the basic thing you need to get your cloud app working is a CNAME record from your domain name to the cloud provider domain (x.cloudapp.net for azure). These guys don't support it and their support people will give you really bad ideas which will break your site links and none of which will work. So, I am currently using NameCheap DNS where this is supported and whose Awesome support team went above and beyond to fix other issues which I will mention here.
"At this point you have two choices:
1. You can use the solution provided below; or
2. You can use a third party's DNS servers and configure them as you like.
I am unsure as to why you are using our DNS servers, unless you're only using our mail service."
But at the very basic level you need this, otherwise it is difficult to keep updating the IP address whenever the instance is deployed and they change the IP address.
2. cheapssls.com which is a namecheap company (just happened by it) provides real SSL certificates for cheap. Be sure to just get one certificate like: *.yourdomain.com - because you can reuse it for sub domains as well.
The real complications come when you try to generate the certificate because you need to have a mailbox working at your own domain name where you can validate the SSL certificate request. Use IIS to generate the CSR request file (it is easy) that can be used for azure web roles as well.
You need an MX record for the email account in your domain for you to get the email. If you have set the CNAME to azure, then by default it will not work.
"We can see that you have a cname record set for the domain @ host name here: http://URL
Please note that cname on @ host name blocks all kinds of mx records. Please set another host record for @ host name. As an option you may select URL frame for this purpose. Changes should take effect within an hour."
Email Namecheap support and they will help get this working. Their support people helped me instantly:
"We have redirected @ record to www.xyz.com via 301 Redirect, while www record remained pointing to http://xyz.cloudapp.net
Now MX records resolve properly and incoming emails should be received."
If you have this problem it will not let you continue with the SSL process. So get this fixed before you move forward and do not move forward without your domain email account working - otherwise when you fix, or when you think you have fixed, you will have to live chat with their support people and have them manually send the email.
Beyond doubt namecheap has the best support people. I was always easily able to connect to someone and they always fixed the real issue, and not just try to close my ticket like lousy discountasp.net guys.
3. Once the SSL is generated, import it into the certificates MMC >> Local Machine >> Personal folder. Right click install does not always work with this .cer file. It can be confusing.
4. Export the certificate to a .pfx file with a password.
5. Upload to your Azure deployment.
6. Select the file in your cloud project properties, enter correct name (full name). Usually the name will be your custom domain name.
7. Specify the end point as SSL and your site will now work with SSL.
You did all this because when you try to use the default examples given online, after sometime, you will get a DPAPI error that the cookie cannot be decrypted.
protected void Application_Start(object sender, EventArgs e)
{
FederatedAuthentication.ServiceConfigurationCreated += FederatedAuthentication_ServiceConfigurationCreated;
}
private void FederatedAuthentication_ServiceConfigurationCreated(object sender, Microsoft.IdentityModel.Web.Configuration.ServiceConfigurationCreatedEventArgs e)
{
// Use the <serviceCertificate> to protect the cookies that are
// sent to the client.
List<CookieTransform> sessionTransforms = new List<CookieTransform>(new CookieTransform[] {
new DeflateCookieTransform(),
new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),
new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate)}
);
SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
}
Then you will see an example code of using a certificate and changing the default to use RSA. This example needs a certificate to work. Obviously with a real site like mine, I needed to get a real certificate. Basically the cookie data needs to be encrypted and decrypted and for that you need a certificate.
The other major headache is to get the web role to be able to read the certificate specified in the ACS tags within web.config (<microsoft.identitymodel>).
This is what works in the web.config file:
<serviceCertificate>
<certificateReference x509FindType="FindByThumbprint" findValue="XYZ" storeName="My" storeLocation="LocalMachine" />
</serviceCertificate>
This is needed in the .csdef file of the cloud project:
<Certificates>
<Certificate name="xyz.com" permissionLevel="limitedOrElevated" storeLocation="LocalMachine" storeName="My" />
</Certificates>
If this does not work, use this:
<Runtime executionContext="elevated" />
And it will take time. Be patient, deploy several times, but in the end it will work.
8. Customize the login page and use a page within your webrole. This is significantly faster than using the default URL which MS provides which does not render well on a mobile phone anyway.
Just note, whatever I have not mentioned, there are plenty of examples online, and they work, but you need the below thing in addition to those articles to really get it to work.
1. Discountasp.net sucks. Because the basic thing you need to get your cloud app working is a CNAME record from your domain name to the cloud provider domain (x.cloudapp.net for azure). These guys don't support it and their support people will give you really bad ideas which will break your site links and none of which will work. So, I am currently using NameCheap DNS where this is supported and whose Awesome support team went above and beyond to fix other issues which I will mention here.
"At this point you have two choices:
1. You can use the solution provided below; or
2. You can use a third party's DNS servers and configure them as you like.
I am unsure as to why you are using our DNS servers, unless you're only using our mail service."
But at the very basic level you need this, otherwise it is difficult to keep updating the IP address whenever the instance is deployed and they change the IP address.
2. cheapssls.com which is a namecheap company (just happened by it) provides real SSL certificates for cheap. Be sure to just get one certificate like: *.yourdomain.com - because you can reuse it for sub domains as well.
The real complications come when you try to generate the certificate because you need to have a mailbox working at your own domain name where you can validate the SSL certificate request. Use IIS to generate the CSR request file (it is easy) that can be used for azure web roles as well.
You need an MX record for the email account in your domain for you to get the email. If you have set the CNAME to azure, then by default it will not work.
"We can see that you have a cname record set for the domain @ host name here: http://URL
Please note that cname on @ host name blocks all kinds of mx records. Please set another host record for @ host name. As an option you may select URL frame for this purpose. Changes should take effect within an hour."
Email Namecheap support and they will help get this working. Their support people helped me instantly:
"We have redirected @ record to www.xyz.com via 301 Redirect, while www record remained pointing to http://xyz.cloudapp.net
Now MX records resolve properly and incoming emails should be received."
If you have this problem it will not let you continue with the SSL process. So get this fixed before you move forward and do not move forward without your domain email account working - otherwise when you fix, or when you think you have fixed, you will have to live chat with their support people and have them manually send the email.
Beyond doubt namecheap has the best support people. I was always easily able to connect to someone and they always fixed the real issue, and not just try to close my ticket like lousy discountasp.net guys.
3. Once the SSL is generated, import it into the certificates MMC >> Local Machine >> Personal folder. Right click install does not always work with this .cer file. It can be confusing.
4. Export the certificate to a .pfx file with a password.
5. Upload to your Azure deployment.
6. Select the file in your cloud project properties, enter correct name (full name). Usually the name will be your custom domain name.
7. Specify the end point as SSL and your site will now work with SSL.
You did all this because when you try to use the default examples given online, after sometime, you will get a DPAPI error that the cookie cannot be decrypted.
protected void Application_Start(object sender, EventArgs e)
{
FederatedAuthentication.ServiceConfigurationCreated += FederatedAuthentication_ServiceConfigurationCreated;
}
private void FederatedAuthentication_ServiceConfigurationCreated(object sender, Microsoft.IdentityModel.Web.Configuration.ServiceConfigurationCreatedEventArgs e)
{
// Use the <serviceCertificate> to protect the cookies that are
// sent to the client.
List<CookieTransform> sessionTransforms = new List<CookieTransform>(new CookieTransform[] {
new DeflateCookieTransform(),
new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),
new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate)}
);
SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
}
Then you will see an example code of using a certificate and changing the default to use RSA. This example needs a certificate to work. Obviously with a real site like mine, I needed to get a real certificate. Basically the cookie data needs to be encrypted and decrypted and for that you need a certificate.
The other major headache is to get the web role to be able to read the certificate specified in the ACS tags within web.config (<microsoft.identitymodel>).
This is what works in the web.config file:
<serviceCertificate>
<certificateReference x509FindType="FindByThumbprint" findValue="XYZ" storeName="My" storeLocation="LocalMachine" />
</serviceCertificate>
This is needed in the .csdef file of the cloud project:
<Certificates>
<Certificate name="xyz.com" permissionLevel="limitedOrElevated" storeLocation="LocalMachine" storeName="My" />
</Certificates>
If this does not work, use this:
<Runtime executionContext="elevated" />
And it will take time. Be patient, deploy several times, but in the end it will work.
8. Customize the login page and use a page within your webrole. This is significantly faster than using the default URL which MS provides which does not render well on a mobile phone anyway.
Comments
Post a Comment