Install Self-Signed CA Certificate to Azure - azure

I need to install a self-signed CA root certificate that is used by one of our applications that uses Client Certificate Authentication with an external provider.
I have uploaded the .PFX client certificate but I also need to install the CA certificate into the trusted roots.
I have googled endlessly on how to do this and everywhere I look it speaks of Web-Roles, Jobs and Workers, Etc.
We don't have any of these on our project and I am not familiar with how they work or the process of creating / using them. We have a standard ASP.NET MVC 5 web application that we publish to an azure app service, that's about it.
How do I get this CA certificate installed on Azure?
I don't mind if I have to use a Web Role / Job / Worker / Whatever but I have never had to configure one before so please advise on how to get setup if that is the correct solution (I.E: If it just requires creating a new project on our VS2015 solution and configuring some deployment settings).
Thanks.
G.

Looking at this blog post it's not possible.
Do note that we will not install new Root certificates in our Trusted Authorities as a result of this, just the intermediate certificates.
That leaves you with two options:
Use an Azure Virtual Machine
Ignore the fact that the certificate is
not trusted by Azure
If possible it would be better to handle the certificate policy in-app - then you are in complete control. Assuming you are using .NET then you can either implement an ICertificatePolicy with your own validation or just ignore the "error" as per this SO asnwer.

If you are happy to run your application on a web or worker role in a cloud service, you can use start-up taks. A start-up task can be either a .bat file or PowerShell script that is executed prior to starting your application. You can also run these scripts elevated if you want.
See also:
- https://learn.microsoft.com/nl-nl/azure/cloud-services/cloud-services-startup-tasks
- https://social.msdn.microsoft.com/Forums/azure/en-US/96926ae6-0cbf-4d00-9dd4-bbe86f93737e/add-certificate-file-to-trusted-root-ca-using-startup-task?forum=windowsazuredevelopment

Related

How to create TenantEncryptionCert in IIS on Azure VM?

I want to create TenantEncryptionCert in IIS's Server Certificates.
I want to know the create step by step.
As Rossano Vitulli-MSFT says in this answer. The TenantEncryptionCert certificates are used by the Azure Guest Agent (GA) & extensions.
The certificate is automatically created and managed by the GA.GA checks for the presence of certificate on startup / update. If you delete it, or if it’s not there for other reasons, then it’ll create a new one.

How to setup SSL Generator for custom domains using Let's Encrypt

I want to setup SSL Certificates generator/manager for Custom Domains - using Let's Encrypt but I'm not able to find the right tutorial. I've done some research work and I'm able to setup Let's Encrypt Certbot on one domain/machine with nginx.
I have a web app on Azure which will serve multiple domains, so multiple custo domains from single IP. I want to generate SSL Certificates for custom domains on the fly.
I learnt that Openresty can help but I couldn't find any step-by-step article. How do I setup the SSL Management with Let's Encrypt. At this point I'm not sure if I need a stand-alone VM or if it possible to run as a set of REST API Endpoint on a Web Server? Any pointers? I appreciate any help!
Azure App Service does not currently include native support for Let's Encrypt, but there is a community-supported extension that gets the job done.
https://github.com/sjkp/letsencrypt-siteextension/wiki/How-to-install
This extension uses a webjob to facilitate automatic certificate renewal, so the app must be Always On for automatic renewal to work. If you are using deployment slots, be aware that you need to install the extension in each slot, and then add a WEBJOBS_STOPPED = 1 slot setting to each non-production slot (assuming you're not using other webjobs on non-production slots that need to run in their non-production environments). This ensures that the webjob is always present on the production slot, and only runs on the production slot.
Also be aware that if you Web Deploy code to the app service from Visual Studio with the "Remove additional files at destination" file publish option checked, that doing so will remove the webjob from the slot to which you publish. You have a few choices if this applies to you:
Manually refresh the certificates every three months.
Reinstall the extension any time you publish (you do not have to reconfigure it).
Clone the webjob into your solution and publish it along with your project.
There may be other options, but those are the ones I've explored.
Microsoft has asserted that this extension constitutes support for Let's Encrypt, but Microsoft does not support this extension. Here's a place to vote for native support for Let's Encrypt on Azure if you think it's important:
https://feedback.azure.com/forums/170024-additional-services/suggestions/16957756-add-integration-with-let-s-encrypt

Can OIOSAML run as SAML SP in an Azure Website?

We are trying to run OIOSAML as an SAML SP in an Azure Website, but we encounter problems regarding the signing certificates. Azure websites will not allow us to install custom certificates, hence our SigningCertificate under the Federation node in the web.config file cannot be found. Do we have to move over to a Virtual Machine?
The Azure Web Sites team is currently working to add this feature. Specifically adding the ability for web sites to optionally load profiles which will support more certificate loading scenarios. The ETA for this work to be in production is within 2 weeks.
To help ensure we will be supporting your scenario, if you can provide a representative code snippet which is failing, we will validate that it works with the fix, before we go to production.
Thanks for your patience.
The Kentor.AuthServices SAML2 SP package can load certificates from files in App_Data and works on Azure. The Kentor implementation is not as complete as OIOSAML (yet, we're working on it) but if the functionality it offers is enough for you it can be an option.

Windows Azure Web Role PublishSettings file purpose

As part of deployment we need to create publish settting file or self signed certificate.
Could someone please help me understand why we need this? To encrypt every request from given machine or any machine?
To publish a deployment from a tool (Visual Studio, PowerShell, or custom using the Service Management API), you will need to authorize that tool to work with Windows Azure. If you deploy via the Windows Azure management portal, this isn't needed because it knows you (via your authenticated Microsoft Account).
That authorization comes in the form of an X509 certificate. Like you mentioned, you can create it yourself, or you can have Windows Azure create one for you in the form of a .publishsettings file. That file contains an encoded X509 certificate. When you import that file into a tool like Visual Studio or the PowerShell cmdlets, the certificate is installed to your local certificate store. Then it can be used to authenticate requests between your machine and Windows Azure.
As for how to manage the certs, I typically prefer to have at least one per machine. I think it makes it easier to remove a cert if I need to, and not impact other machines I'm using. But, that's really up to you.
I always assumed the certificate was needed to authenticate the right to publish
(you don't want just anybody being able to deploy to your site)

X509Certificate2.Verify() returns true in console app, false in asp.net web app

I've a feeling it's something to do with the permissions of the AppPool but as this app is hosted in Azure it's not possible to change that.
My code works in a console app and when the AppPool is set to run as a user (myself). It fails to run when the AppPool is set to run as ApplicationIdentity and when the service is hosted in Azure (I'll post the code if requested, but I don't think that's where the problem lies).
It doesn't matter whether I load the certificate from a store, from a file, or from a byte array. The results are the same.
I don't know what information will be helpful in diagnosing this but it appears that the chain/path doesn't load under the reduced privileges. Calling .Verify() returns true in the console app (and IIS running as my user) and false under ApplicationIdentity.
The certificate appears to load normally and contains a private key in both circumstances.
It turns out my problem was the same listed in this question. I needed to set my certificates up so that some of them were in the CA and Trust section so that the chain was built correctly.
I had all of the certificates installed but it would appear that the location of the certificate is important as well, and it was nothing to do with security or which user was logged on at all!
You can change almost anything in Azure. It is full IIS (if you are not upgrading from SDK 1.3 or earlier) by default. There are couple of options to try:
(This one is wrong! Noted by Steve Marx)Try jus trunning the application (in this case IIS AppPool) in Elevated mode. That will make AppPool running under "SYSTEM" account, instead of AppPoolIdentity. You can do that by adding a <runtime executionContext="elevated" /> element in your role definition in .CSDEF file.
You can enable remote desktop to all your roles. That will effectively create an account in your role instance and add it to the Administrators group. Then you can use a startup task and powershell script to change AppPool identity to use that account instead: A blog post by Wade Wegner on how to programatically change AppPool Identity.
Well, these all are ways to make your application pool runs in Elevated mode, but also show that you can do pretty much everything with IIS on your Windows Azure Instance. I suggest to use site runing in elevated mode only for testing purposes. First make your code run in restricted account on local IIS. Then see what you changed to make it wokrk locally and apply these changes on the Azure Web Role.
EDIT
Another thing to pay attention is that in order .Verify() to work, you must have the Root Certificate of the CA that issued the checked certificate, installed on the web role. This can be done via adding the Root CA Certificate as a "Service Certificate" from the management portal. Also, the CA that issued the checked certificated must be trusted.

Resources