We are planning to create and install self-signed certificates on azure web roles.
We have a requirement to create certificate on web role itself and installing there.
But we cannot find makecert.exe on azure web and worker role. We did remote desktop on azure role and found that makecert.exe is missing.
Any direction on creating and installing certificate on azure role would be helpful?
If there is any management APIs available for creating certificate on web role, please share with me as I am unable to locate in msdn.
You have a few options to create self-signed certificates:
Deploy makecert.exe with your application (include it in your VS project, set Copy Local = true)
Write something yourself to generate the certificate (example here: https://github.com/mono/mono/blob/master/mcs/tools/security/makecert.cs)
But there's more to it than simply generating a certificate. What will you do if you have more than one instance running? Will you install the certificate on 1 instance? Or do you need all your instances to have the certificate? What if you redeploy the application? ...
In those cases you might want to look ahead. Would it be an option to store all those certificates in blob storage? Maybe you could have a process running on each instance that 'synchronizes' the certificates with the current instance. You could also use AppFabric ServiceBus Topics to notify other instances when a new certificate has been generated...
The direct answer to your questions is that Makecert.exe is an utility which is installed either from installing Visual Studio or Windows SDK or direct download from Microsoft sites. A Windows Azure VM sure not to have this makecert.exe because it is not part of base Windows deployment and if you want to use/run Makecert in Windows Azure VM you really need to add in your project and deploy it.
HOWEVER,
If you have a need to deploy a certificate to Windows Azure you really don't need to generate it on fly (i.e. using Makecert.exe) because there is other easier way to do it. You just need to add (or deploy) your PFX certificate to your Windows Azure Service -> Certificate section and when you VM will be initialize, the certificate will be provisioned to your Windows Azure Role (Web or Worker or VM) so there is no need to add Makecert.exe with your project and then use Startup task to run it.
Instead of depend on Makecert.exe or any other method to have certificate in your role, i would suggest using above method which is actually designed for such requirement. If you don't know how to deploy a certificate to your Windows Azure Service either directly to portal or using PowerShell, please let me know..
Related
I have created an image of my TWAS application and deployed it in a container inside an openshift POD. In my TWAS ND I use to go to the admin console WebSphere environment truststore on a node on a virtual machine and set up TLS certificates so my application can have communication with external API's in the secure communication channel HTTPS. These certificates are public certificates and don't have any private keys. They are .crt and .pem files. Now I am wondering how I can set up my third-party TLS certificates for my application running inside the POD as a container? I don't want to make any code changes to my J2EE application which I have migrated from on-prem VM to Openshift.
Note: I am using TWAS base runtime here and not liberty for my newly migrated J2EE app on openshift.
When you build your application image, you can add a trusted signer and a short script into /work/ prior to configure.sh
https://www.ibm.com/docs/en/was/9.0.5?topic=tool-signercertificatecommands-command-group-admintask-object#rxml_atsignercert__cmd1
AdminTask.addSignerCertificate('[-keyStoreName NodeDefaultTrustStore -certificateAlias signer1 -certificateFilePath /work/signer.pem -base64Encoded true]')
AdminConfig.save()
The root signer might not be either the pem/crt you have, those could be the issued certificate and the signers. WebSphere allows you to setup the trust at any level, but it's ideal to trust the root CA that issued the cert.
We've also used a technique of importing a trust store into a Secret and mounting that into the expected location in the pods. This might make sense if you want to isolate any certificate changes from the app build cycle.
I'm quite new to the .NET Workflow stuff.
I've made a workflow service and now I want to host this service using IIS. (This workflow was well tested by debugging it in VS2012)
I'm using AppFabric and Workflow Manager to configure all of this.
Workflow Manager made all the databases needed to persist the workflow instances and the Workflow Management Site in the IIS. Then I've published my workflow service into a zip file and imported this into my Workflow Management Site.
Everything was fine and running when I had shut down my computer two days ago. Now my Workflow Manager Backend service won't start anymore. When I watch the eventlogger this is the critical error:
The Workflow Manager backend failed to start at location 'WorkflowServiceBackendHost.Start' due to an exception: System.InvalidOperationException: Certificate '90ED72666C964EE0902E84767A0D284D66F6B725' is not found in the certificate store.
I found the sha1 of this certificate in 'Microsoft.Workflow.ServiceHost.exe.config' file in 'C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts'. But it's not possible to change it and try something else. So I guess it was a generated certificate by the Workflow Manager configuration.
I searched in my certmgr.msc for this sha1 and could not find it. But I didn't change or remove any certificate and I don't think that the certificate could be expired because I installed and configured everything two days ago. I don't think this is the same certificate that is used for the communication between the service and an external application.
Maybe I could change something in the Workflow Manager configuration but this tool doesn't start. Probably because the service isn't started. But as I said I'm new to all of this and the information I found this far didn't help me or was re installing the workflow manager etc. But then I wonder what will happen if all of this is in production.
Could anyone help me to get this Workflow Manager backend service up and running again?
Thanks in advance, Tim
Reset the Auto-Generation Key for WFM and Service Bus
i. $CertKey=convertto-securestring ‘YourPassword’ -asplaintext -force;
1. Note: Update with YourPassword with your own password
ii. Run this step:
1. Set-WFCertificateAutoGenerationKey –Key $CertKey
iii. Followed by this step:
1. Set-SBCertificateAutogenerationKey –Key $CertKey
iv. Update the Hosts:
1. Stop-SBFarm
2. Update-SBHost
3. Stop-WFHost
4. Update-WFHost -certificateautogenerationkey $CertKey
5. start-sbfarm
Check that the Get-WFFarm and Get-SBFarm output has changed certificate thumbprints
We have a tool that we need to integrate in our automated build process (we use TeamCity for our automated builds). The tool talks to a WCF web service that is configured for SSL certificate authentication.
I have searched around to see how this can be done in TeamCity. Unfortunately all I've found seems to be authentication between TeamCity Server and clients or plugins.
How can I consume a certificate in my machine certificates store if a running TeamCity agent as a Local System account for example. It seems when running it in this account, it does not have access to the certificates.
Thanks in advance for your help guys.
The problem comes from the fact that Local System Account can not find the certificated installed by other users on the machine.
You can install a system wide certificate Or you can run a command line under Local System Account and install the required certificate.
You can use psexec from SysInternals suit to get the command line
psexec -i -s cmd.exe
And install the certificate from command line
I've developed a c# (.NET 4.0) application that signs PDF documents using SecureBlackbox libraries. For my signatures, the signing process uses some installed user certificates from Trusted Root Certification Authorities and Intermediate Certification Authorities. The signing works when I open my testing application as a user, but when i implement this module in a WCF service on IIS (using LocalSystem identity for my Application pool) it doesn't work because it cannot find those certificates.
Note that I've additionally installed those certificates using mmc.exe in Computer account -> Local computer snap-in, but that doesn't solve it. I've also tried to add them to Service account -> Local computer -> World Wide Web Publishing Service (that's IIS, right?), and no success...
Can anyone suggest something else to try? I am not sure at all what IIS is using as account or even if it can access my certificates at all in some other way, please help.
Make sure the cert has read permissions for Local System (if that's what your iis process is set up to run).
What I've found to be correct is that when you use ApplicationPool with identity LocalSystem, the certificates that belong to the system can be managed with mmc.exe when adding snap-in: Computer account -> Local computer. The actual problem was my bad coding while fetching certificates from system store using SBB library. I've solved that and therefore i've solved the problem.
I want to move my MVC application from Azure to an in-house server. How do I export the SSL certificate associated with the App to install it on the local server?
Is it at all possible?
NO. There is no way to get certificate out of Windows Azure. Question is how it (the certificate) appeared in the Azure at first place. It was certainly not uploaded by Microsoft people or some magic. It is a developer who packed the deployment package to include the certificate reference (thumbprint) and service administrator (or co-admin) who uploaded the original certificate in the Azure. So contact that people (whom might be just you?) and ask for the original certificate.
If certificate is lost, contact the original issuer (certification authority) for a copy, if you were the one to originally requested. If you did not originally requested the certificate, there might have been a reason behind that.