My company has got a software that is used on-premise and installed as a Windows service. We are adding now a WebAPI to it using .NET core 2.1. This API should be secured with SSL and if we buy a certificate it will last at most two years. Is there any way of automatically updating the certificate used for HTTPS? Some customers buy the software and don't upgrade as often as we would like. How could we ship a new certificate for them?
Update 07/03:
Our on-premise solution has been working at the backend as a service for 6 years (with two major updates per year). Now we are integrating a webapi in this service. No IIS here, just a self hosted webapi. Our service could use our own SSL certificate but then we will need to replace it somehow when it expires.
How could I ship SSL certificate update to a running app?
You don't need to distribute the server certificate to client devices if it is signed by a CA they trust.
Ideally the client systems should trust a Certificate Authority (CA) that has a very long validity period (e.g. 20 years). That CA then issues short-lived certs (e.g. 6-12 mo) to the webservers. The clients will trust these certificates because they are signed by the CA they trust.
This is how the public web works today. The CA's are companies with big insurance policies, like Verisign, and the OS or browser vendors determine whoch CA's make the cut and get included into the certificate bundles which they manage by their own mechanisms (e.g. automatic updates).
So an option is to simply buy an HTTPS certificate from a public CA.
You can also be your own CA, but then you need to manage protecting the highly-sensitive root CA keys, and the distribution of your CA cert to all of the client devices.
Related
I've created an API and deployed to Azure (be patient I'm new to all this). The API will be used by a single daemon app in another organisation. I'm planning to secure this by:
IP White List - this seems to work an to my mind makes the API pretty damn secure.
Client secret create by AAD - is this sufficient?
HTTPs - I've turned this on (Azure APP service TLS blade). However it just seems to work which always makes me suspicious, do I need to link a certificate? Is the encryption being handled behind the scenes?
If it's sufficient or not depends on your scenario. (e.g. is it hipaa / pci compliance?)
I would also add a Azure Key Vault for storing the secrets; WAF (Web Application Firewall) in front of the API + API Gateway (using API Management).
Your point #2 looks useless to me, you'd better request your client to authenticate against your azure Ad and pass the acquired token to your API. this way you'll know who / when called your service.
#3- Azure gives you a SSL certificate, but if you plain to use your custom domain (recommended), you could either generate a certificate using Let's Encrypt or buy from another trusted authority. The encryption happens at rest and in transit, but you could also use your encryption keys for the encryption at rest part.
I'm working on some WCF application. I already have client-side and server-side. Both communicates using WCF netTcpBinding or netNamedPipe. I want also a certificate only on server side, similar as it is with HTTPS. I've found very helpful guide here click.
So according to this article, I'm interested in option 1 which is
Option one provides (C + I) no authentication will happen for the client, In this case the TCP SSL (not the HTTPS SSL) will be used to provide the Confidentiality and Integrity, and the service will be configured like this below.
For now everything is clear for me, unfortunately later we can read:
also you need to install the root certificate authority certificate for the service certificate on the client machine (typically in the Local Machine/Trusted Root Certification Authorities), and the service needs to have the below behaviour to specify the certificate for the service.
So here comes my question, is there any way to avoid changes on client machine? As mentioned earlier, I'm looking for a solution similar to WEB where the user is not obligated to install any kind of certificate on his machine.
Maybe I'm missing something, but maybe this rule applies only when I'm using a self-trusted/developer certificate? What if I will get certificate from a trusted company like Verisign?
Install the certificate on the client-side simply to guarantee that the service on the server-side is trusted and that communication I secure. Just like visiting a website, we usually have a built-in certificate for the site before we browse the website, so the browser prompts the website is trusted. Unlike self-signed certificate, website certificates are issued by trusted third-party organizations to a specific host (web server), so all we need to do on the client-side is to install authoritative trusted third-party certificate before accessing the website. but we directly install the server-certificate on the client-side when we configure a self-signed certificate in the Local CA.
In fact, Browsers/OS already have some authoritative third-party certificate built-in. such as GlobalSign, VeriSign, so we just need to buy a certificate from them and configure them on the server-side, in which case, the client always trusts the server.
In addition to installing the server-side certificate, we may also need to configure the server-side identity on the client-side, which is usually the public key of the certificate, or the hostname. These configurations are generated automatically if we generate the client proxy and invoke the service by adding a service reference.
Feel free to let me know if there is anything I can help with.
You don‘t need install somethings when you use an certificate issued by an trusted CA like GoDaddy and so on.
Before writing this question I have gone through a lot of questions and answers but I can't seem to find a solution. What I'm trying to do is host an application as a Azure App Service that needs to make a call to the Swish API.
Please see this thread for how my implementation runs locally which works fine:
C# HttpClient with X509Certificate2 - WebException: The request was aborted: Could not create SSL/TLS secure channel
System diagnostics log from Azure:
https://pastebin.com/EBFb3zrA
I have tried the solutions from Microsoft forums and SO but none seem to do the trick:
https://social.msdn.microsoft.com/Forums/azure/en-US/ca6372be-3169-4fb5-870f-bfbea605faf6/azure-webapp-webjob-exception-could-not-create-ssltls-secure-channel?forum=windowsazurewebsitespreview
//Tested both, none of them work
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
//ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11
Since a lot of the questions are based on accessing an external service and not sending a client certificate the complexity rises a bit as well.
What I have done is in the SSL certificates tab on Azure import the Test certificate. Since .p12 and .pfx are both PKCS #12 files I just renamed the .p12-file. The application runs as B1 Basic App Service Plan so most functionality should be present.
https://stackoverflow.com/a/6821061/3850405
I have also tried this guide to add the certificate to the certificate store in Azure -> Application settings -> App Settings:
https://azure.microsoft.com/en-us/blog/using-certificates-in-azure-websites-applications/
When this did not work I tried to add WEBSITE_LOAD_CERTIFICATES to appSettings in my application but it resulted in a HTTP 503.
Swish certificate and English guide:
https://www.getswish.se/content/uploads/2015/06/Guide-Testverktyg_20151210.zip
We were able to make this work in an Azure Web App. The trick was the appSetting WEBSITE_LOAD_CERTIFICATES and to upload all Swish certificates in the Azure portal. That is, the .pfx file from Swish contains three certs where two of them are root certs. So we exported the root certs and uploaded the .cer files under TLS/SSL settings -> Public Key Certificates (.cer) and then it started to work. You also need to upload them to all deployment slots since the certs will not be automatically copied to the slots.
According to your scenario, I also checked by adding cert file to a Resources File and construct the X509Certificate2 instance by the following code snippet:
var certBytes=(byte[])ResourceManager.GetObject("Swish_Certificate");
var certificate = new X509Certificate2(certBytes, "swish");
Per my test, I assumed that you could not implement Swish payment on Azure Web App. Additionally, you could add your feedback for azure web app here.
I have implemented SSL connection in my application. For this I have added IIS Express Development Certificate while hosting the site in IIS.
I could use other pages with SSL. ie., https://localhost/general
I am unable to login the application using SSL. My url changing like https://localhost/accounts/login and becomes empty page.
I am getting the below error in Firefox browser.
This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.
I have tried by using Self-signed certificate also.
Is this problem arise because of IIS Express Development Certificate ??
Either you use full IIS or IIS Express, the default self-signed certificates generated are SHA-1 only, and now become obsolete.
To generate SHA-2 certificates, you can use Jexus Manager,
https://blog.lextudio.com/2016/03/jexus-manager-enhanced-self-signed-certificate-generation/
I've been using the ThinkTecture Identity Server to experiment with federated security and claims based authentication in Windows Identity Foundation. I'm running Identity Server on a separate box, using a self-signed certificate created in IIS for SSL and encrypting tokens in Identity Server.
I'm running a local MVC application, configured to use Identity in Visual Studio 2013 by pointing the identity tool to the FederationMetadata file for Identity Server. Part of this configuration includes a <trustedIssuers> section, which includes the thumbprint of the certificate of the Identity Server.
All that is pretty straight forward, but I'm confused as to how the thumbprint is being used on the client to trust the Identity Server. Originally, I thought that somehow the thumbprint value was used directly in validating the token issued, but reading more into it I've found that the thumbprint is used to look up the actual certificate on my machine. However, to my knowledge I never had to export the Identity Server certificate and install it on my client machine, it just worked.
How is WIF using the thumbprint in this scenario, if I do not actually install the certificate myself?
By default - the public key to validate the signature is embedded in the token response - that means the RP does
Validate the signature using the embedded certificate
Create the thumbprint (hash) over the embedded certificate and make sure that matches the configured thumbprint.
This way you don't need to deploy the cert on the RP.