Develop Reference

How to create and configure SSL certificate on windows 10 IIS

I am doing development on Local host. I need SSL enabled for a module. I have generated Self Signed certificate for it on IIS. But when I run my site it says not secure.
I have even Edited Bindings of the site for Port 443

Try to Secure the server with SSL.
1.In your IIS Manager go to your server -> Scroll down and double-click Server Certificates.
2.Click Import…, you need to import our self signed server certificate in order to enable https communication with SSL.
3.Your certificate is now added, double-click the newly added cert to verify that it is trusted.
4.Now you can add the https binding, Choose https with port 443, your domain as the host name and find your self signed certificate in the drop down list.

.NET configure server certificate for an application

I am totally new to .NET and I came across one problem that is related to an agent application.
Its an IoT agent application which will be deployed and run Windows and Linux systems.
The application is a Web Service based application and uses HTTPS certificate to enable the secure communication between the clients and agent. When I tried to run the application on one of the system, I got error as
System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found.
After going through most of the posts, I found that we need to download and install the 'dotnet' run time on the system and run below commands
dotnet dev-certs https
dotnet dev-certs https --check
However, for development environment its okay to run these commands. I am looking for a solution where we can run the application without download and installing the dotnet runtime environment.
What are the initial configuration settings those may required to run the application?

It's not the runtime you are missing (you wouldn't be able to execute the application and get the exception). You are missing a valid certificate for your server.
On a development machine you would issue the command
dotnet dev-certs https --trust
to install a trusted self signed certificate. On a production server you have to install a certificate from your certificate server or if it's public accessible from a trusted certificate authority.

Finally, able to run the application on Windows 7 and Windows 10 machine with the PFX certificate.
You need to generate the certificate. You may follow below link to generate the certificate.
https://www.sslsupportdesk.com/export-ssl-certificate-private-key-pfx-using-mmc-windows/
It is required to configure the Kestrel settings in JSON file. Below is the possible JSON configuration to use the certificate
{
"Kestrel": {
"Endpoints": {
"Https": {
"Url": "https://localhost:9448",
"Certificate": {
"Path": "path/to/certificate/file/your-cert.pfx",
"Password": "PwdOfCert",
"AllowInvalid": true
}
}
}
}
}

Air-gapped .NET code-signed application will not install/run

We recently updated our applications to make use of SHA-256 code-signing with a new certificate. The assemblies are strong name signed using the Sign the assembly option in Visual Studio 2015. The post build event in Visual Studio runs two signtool.exe processes to sign both in SHA-256 and for the legacy SHA-1 certificate:
call "C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe"
sign /f "<mystrongName.pfx>" /p "<password>" /t
<timestampURL> "$(TargetPath)"
call "C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe"
sign /f "<mystrongName.pfx>" /p "<password>" /fd sha256 /tr
<timestampURL> /td sha256 /as /v "$(TargetPath)"
Finally we use Advanced Installer as the installation packager and that too is code-signed on the Digital Signature page using the certificate and timestamp as per the .exe signature.
The final setup file installs and runs on Internet connected Windows machines as you would expect. You can see the certificate is assigned and valid, as well as the certificate chain through the properties of both the setup.exe and the runtime when installed. Furthermore, Windows recognizes the application as from a trusted source and displays the appropriate verified publisher details.
Our customer-base is largely global 100 companies and most of the deployments will be occurring in air-gapped networks. In one of our fist updated deployments in this environment, the certificate could not be verified preventing the installer from completing.
This made sense, because the Windows (2012 server R2) machines were isolated from the Internet and, due to company policies, had Turn off Automatic Root Certificates set to Enabled. This setting can be found in the Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication Settings folder of the MMC application (you need the certificates plugin installed).
When testing on our local test-bed, even machines not connected to the Internet would install the certificates from the setup utility if the above registry setting was the default (Disabled). We could replicate the issue by changing the policy setting to match the customers' (Enabled).
As a workaround, we manually downloaded the Certificate Authorities root certificate and installed it as a Trusted Root Certificate and the install would proceed normally.
When we presented this workaround to the customer, the installation still failed despite the Certificate Authorities root certificate being present in the Trusted Root Certificates of the machine.
The Certificate Authority customer service team recommended that we drop the timestamp from the signing process to allow the install to proceed - and that's the only help they offered (that's another story). However, this means that once the code-signing certificate expires, the application will either cease to run or will present unverified publisher errors.
I'm not totally convinced that this will fix the problem either, because when we tested locally the certificate was still found by the installer and allowed the installation to proceed when the Certificate Authorities root certificate was installed manually.
What I am unable to do is replicate the customers environment to exactly reproduce the problem (which doesn't help). It is almost as if Windows is bypassing the local machine's Trusted Root Certificates store. I am assuming that if this is possible it would be so that Windows can verify against a central root certificate store.
Is this even possible to set up in Windows? If so, where would I find either documentation on this or how is this done?
Am I missing something in the code-signing steps or in my understanding of what should be happening on the installing machine while it is checking the certificate?
I am at a loss as to what to do to get this installer working. What I can't afford to do is keep going back to the customer to get them to keep testing our installs. First-off it's really not the right process to debug, as the supplying vendor it isn't the customers problem to solve, but more importantly, I need our team to understand what is causing this and how to remedy it correctly.
Ideally I don't what to drop the timestamp if I don't have to because down the road this will cause new problems if the software doesn't get upgraded before the certificate expires.
Any and all help much appreciated.

I think one reason a certificate cannot be validated in an airgapped environment may be that revocation cannot be verified. As you may know, a certificate can be revoked, and there are two different protocols to check if it is, CRL and OCSP. Both require network access to the CA that issued the certificate.
Whether revocations are actually checked is governed by policies as described here, and this may cause your issues.

Azure deployment update - Mismatch between the certificates of the running service and the certificates in the uploaded sdk package

I'm trying to change the remote desktop certificate of an older application running in Azure.
I created the new certificate, exported it and succesfully uploaded it to the cloud service certificates (in Azure portal)
So far so good but when I try to update the cloud service by uploading a new package with the new certificate then I get this error:
Mismatch between the certificates of the running service and the certificates in the uploaded sdk package
How can I overcome this? The cloud service builds and works fine if I keep the old certificate thumbprint.

Check that the thumbprints of the certificate uploaded to the portal is the same with what you provided in ServiceConfiguration.Cloud.cscfg.

Seems you are doing things right for RDP cert. I have a pair of pfx made from makecert and upload them to cloud service, and can switch thumbprints around in CSCFG file without any deployment problem.
My assumption is, you have used this cert else where in your service resulted the error.
Referring to step 2 in this article, is it possible you are using cert but missing something in the service definition(CSDEF)? Such as CA certificate reference or intermediate certificate block.

The security certificate presented by this website was issued for a different website's address

I have two projects. One is WCF project and the other one is client. The WCF project is hosted by IIS which uses SSL.
I created self-signed certificate by IIS And bind the certificate to URL:localhost:4435/Service1.svc. When use IE open the site, it shows 'The security certificate presented by this website was issued for a different website's address.'
The certificate is already exported in the "Trust Root Certification Authorities".
Via Visual Studio, I can add service reference for client，but when I call the service, it show me the "Could not establish trust relationship for the SSL/TLS secure channel with authority 'localhost:4435'."
I am in trouble, wish someone to help me,
Thanks.