if we need to secure web site or use HTTPS for our web site then we need to use certificate at iis level. in development pc we often use Self-Signed Certificates which can be created very easily from IIS.
i visit this url http://weblogs.asp.net/scottgu/archive/2007/04/06/tip-trick-enabling-ssl-on-iis7-using-self-signed-certificates.aspx to learn how to create & use SSL for our site
after doing everything when we run or test the site in local pc then i feel Self-Signed Certificates does not work like real life certificate which people buy. here i am adding couple of picture from there you can see what kind of problem i am talking about.
just see the second picture and look at url. in case of ssl a lock sign come with green color.
so just guide me what else we need to do as a result Self-Signed Certificates just works like real life certificate in my pc. please discuss this in detail or redirect me to right article which can show what else to configure as a result browser address bar should properly reflect for SSL.
thanks
The certificate works the same. The problem is that a self-signed certificate is not always included in the browser's Trusted Issuing authority. If your sole purpose is for development, you can follow this method here of adding your issuer (self) to trusted authority or adding the certificate itself as trusted.
In production website, you need to purchase an SSL certificate because your visitors' browsers cannot trust self-signed certificates as they cannot verify the issuer.
Having said that, for development and testing purposes, the behaviour you described is fine, but if you really need to get rid of the warning, you need to register the certificate in your local PC (all PCs that you don't want to see the warning on) and then use the same certificate for your website in IIS.
Follow this guide from step 2 onward, but here are the outlines:
First you need to copy the certificate to your local PC:
In IIS, export the certificate to a file.
Copy the file to your local PC.
Use MMC to import the certificate from the file. Make sure you import it to Personal folder.
Repeat the last two steps for all PCs.
Now that you have the certificate registered in your local PC, you need to tell your PC to trust it:
View the certificate in MMC and go to the second "Details" tab.
Scroll-down to the "Thumbprint" and selected it to display the certificate hash.
Copy the has into the clipboard (the hash identifies your certificate).
Open Notepad and paste the hash there.
Remove all the spaces from the hash using the "Replace" feature in Notepad.
Use the hash in the following command:
netsh http add sslcert ipport=0.0.0.0:443 appid={214124cd-d05b-4309-9af9-9caa44b2b74a} certhash=PASTE_YOUR_CERT_HASH_HERE
Note: The "AppId" doesn't really matter, its just a GUID.
In MMC, move the certificate from the Personal folder to the Trusted Root Certificates folder.
Related
I have an application that can be downloaded from my website and run on user PC. This application doesn't do anything special and just allows the web page to access the scanner. It uses SignalR for communication.
Basically, I run SignalR server under WinForms application and have javascript client that tries to access it through http://localhost:8084/signalR.
Everything works fine when I use HTTP version of the web application, but fails, when I use HTTPS for my web application: Most of the browsers don't allow unsecured connections from a secure page.
So, I've created a self-signed certificate that is installed on user system during installation and it works fine for Chrome, IE and Opera, but fails for Firefox and Edge.
So I was thinking, is there a better way to access SignalR applications that are running on localhost from webpage under https?
There isn't a better way. You are correct in your understanding that "[m]ost of the browsers don't allow unsecured connections from a secure page". I believe there isn't a browser that will allow this. Therefore if you want to call out from a secured website, you must use a secured connection as well.
I don't know the issue you're experiencing with Edge, as I can confirm that it does work. Firefox will NOT trust a certificate in the cert store, even if it is a trusted root or has a trusted root certificate. You have to manually add an exception for this certificate. Details, or at least information that will let you find the correct method to do this, can be found here.
There are some things you have to do in order to make sure your certificate and configuration is correct. First, you have to have a well formed certificate with a public and private key and a well formed certificate authority cert with only its public key. By "well formed" I mean it must contain all information required by browsers for full trust, such as a Subject Alternative Name entry.
You can use OpenSSL to generate the CA, then use that to sign a certificate you will use for the SSL port. Export the CA's public key and the SSL certificate's public and private keys. Exporting the CA's private key is a MAJOR no no. That would allow third parties to create new certs from it and install them on your client's machine. The CA gets installed in the machine's Trusted Root Certification Authorities store. The SSL cert can go into the Personal/Certificates store.
Once you have these, you have to configure the URL/Port you will use for access and SSL using the netsh command line tool. Add a URLACL to allow the application to access the url and port (netsh.exe http add urlacl), and then assign the certificate to the port (netsh.exe http add sslcert ).
Having done all this, you should be good to go. The only real problems you should have are Chrome being very demanding about the configuration of your certificates and Firefox refusing to trust your CA certificate even though it is in your trusted certificate store. Bastard.
And for Edge, I can definitely guarantee if you do all the above it will work. If it doesn't, you need to consult the js console to see what errors it is throwing.
I have looked at about 10-15 different pages about the SSlStream class and about certificates and I haven't found one that completely explains everything to me. So I have a bunch of questions.
I am currently working on some SslStream code and I have a question about certificates. From my research it appears that the server requires a certificate if we are using TSL12. And it appears optional that the client needs a certificate.
1) Now if we design a system that the client needs a certificate do we use the same certificate for the client and the server? Or do they both use different ones?
2) Also looking at the Microsoft SslStream help page:
https://msdn.microsoft.com/en-us/library/system.net.security.sslstream(v=vs.110).aspx
How does the code know if those are the expected certificates?
3) In the Property page on a project under Signing you can Create a Test Certificate. When you click that button it asks for a Password. If a password is used how would that affect the SslStream code? The code on the Microsoft help page above doesn't deal with that at all?
4) Once I have a certificate for the server and the client can I just place them in a directory or do I need to put them in the store?
Thanks.
You can find most answers to your questions here
These are the different certificates. Client certificate used to check client identity. Server certificate used to encrypt key materials and to authenticate itself.
What means expected? You mean whether the client certificate is correct? You can write your own login to check client and certificate. By default expiration date is checked, where it's revoked or not etc. Read there to clarify.
It will create certificate and to use private key you will need to provide password to get it from storage
The base usage is to put it into the store. But you can also get it from .pfx file. You can read there about geting the key from file
1) Now if we design a system that the client needs a certificate do we use the same certificate for the client and the server? Or do they both use different ones?
The best practice is "one certificate per purpose". Think of a server authentication certificate as the "Warner Bros. Studios" sign hanging on the building as you pull up to the guard shack, and a client authentication certificate as an employee ID badge. They both inform the other party what's going on, but it feels a little out of place to then walk down the street to Universal and show your big Warner Bros. sign as identification.
2) Also looking at the Microsoft SslStream help page: https://msdn.microsoft.com/en-us/library/system.net.security.sslstream(v=vs.110).aspx How does the code know if those are the expected certificates?
The server authentication certificate you provide is correct, because you provided it.
If you give only one client auth cert, that's correct, because you provided it.
If you give multiple client auth certs then it will use an acceptable CAs list provided by the server TLS handshake to reduce the list, then it takes the first one that was acceptable.
3) In the Property page on a project under Signing you can Create a Test Certificate. When you click that button it asks for a Password. If a password is used how would that affect the SslStream code? The code on the Microsoft help page above doesn't deal with that at all?
Certificates don't have passwords, but PFX/PKCS#12 files do. You need that password to load the file into an X509Certificate2 instance (e.g. new X509Certificate2("servercert.pfx", "1Potato2Potato3Potato4")). Since SslStream won't do the loading for you, it doesn't talk about passwords.
4) Once I have a certificate for the server and the client can I just place them in a directory or do I need to put them in the store?
They should work fine when loaded from a PFX (you need the private key, so it can't be just a .cer). If the certificates can be one-time loaded into cert stores you can avoid the problem of loading or hard-coding PFX passwords... but that just depends on your deployment needs.
I have installed a .pfx to my Azure website using the management portal upload certificate.
I am now trying to access them using the code below:
X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
certificateStore.Open(OpenFlags.ReadOnly);
var certificates = certificateStore.Certificates;
StringBuilder sb = new StringBuilder();
foreach (var certificate in certificates)
{
sb.AppendLine(certificate.Subject);
}
When published to Azure, a bunch of certificates are listed but not the one that one that I have uploaded.
The certificates listed are here:
CN=WW.azurewebsites.windows.net, OU=CIS(RD), O=Microsoft
CN=FullOSTransport
CN=client.geo.to.stamp.azurewebsites.windows.net
CN=ma.waws-prod-am2-005.azurewebsites.windows.net, OU=OrganizationName, O=Microsoft,
L=Redmond, S=WA, C=US
CN=FullOSTransport
CN=FullOSTransport
I purchased the certificate from Verisign and it appears to be uploaded correctly and does appear in the 'HTTPS' bar in the browser (in Chrome).
Any help would be really appreciated as I'm at a loss here.
Update
It looks like we would need to convert to a Cloud Service for the above code to work. But can I add the certificates to my app_data folder as suggested here?
http://blog.tylerdoerksen.ca/2015/11/29/pfx-certificate-files-and-azure-web-apps/
This seems to work for Azure-Websites without the use of web roles.
Thanks
I have faced the similar issue, below is the solution that worked for me.
Solution:
once you have uploaded your certificate through the Azure portal you need to add an appsetting (also through the portal) called WEBSITE_LOAD_CERTIFICATES and set the value for this to the thumbprint of your uploaded certificate. This can be a comma separated list of multiple thumbprints if you want, or even * to load all your uploaded certificates
Then load ur certificate using the below code.
var store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
var certs = store.Certificates.Find(X509FindType.FindByThumbprint, YOUR_THUMBPRINT, false);
I have installed a .pfx to my Azure website using the management portal upload certificate.
I recently had to go through this process for an Azure Web Site so these are the things I would try in this order to save the time.
What you can do to debug?
First, remote into the machine and find whether the certificate exists there. You can find that using mmc.exe and add certificates snap-in. See here for complete instructions.
In the case of an Azure Web Site, you have to enable the remote desktop by going into Azure Management Portal, and then create a session into the VM that has your Web Site deployed.
Deploying certificates
If certificate does not exist, you will have to deploy it. For testing, you could do it manually by going into the VMs using the remote session and importing the certificate.
In the case of Web Site, if you want it to be deployed automatically, you will have to update the service definition files for that role to make sure that the certificate will be deployed properly. Also, keep in mind that your certificate should be uploaded as a "Service Certificate" and not a "Management Certificate" if you want your roles to be able to use it. If you are using Visual studio, you could also add it to your project and that may deploy it.
Permissions
Additionally, (and especially if you had manually deployed the certificate e.g. on a VM), you will need to check that IIS has permissions to access the certificate. This page here explains deploying certificates and how to give appropriate permissions. If your certificate is included in the deployment package, then this is not necessary as Azure Deployment will take care of it.
FYI: It works locally because the certificate already exists in the store your code is looking into, and there's nothing that is going to remove the certificate (unless you do it manually) to verify that if you deployed locally again, the certificate will be deployed again (assuming that your deployment locally and on Azure cloud is exactly the same). In many cases, the local environment and Azure cloud environment can be different (unfortunately), because Azure will provision clean VMs, and everything needs to be deployed properly. On the local machines, we have a lot of "leftovers".
We've been working a lot in an application developed in VS 2010, C#, and WCF. We use Transport as the security mode, and in the TransportSecurity Properties set to None and None.
We are hosting the service in IIS6. After working a lot we managed to make it work using https. The Certificate we used was a self created one, created with the selfssl.exe tool. After creating the Certificate and storing it in the "Trusted Certificates" list, we set it as the Server Certificate in IIS for our Site, and also do the "binding" between the Certificate Thumbprint and the localhost address with the 443 port, using the httpcfg tool.
Well, we also use the famous piece of code not recommended for production (we are aware of that) that enables the validation of a Certificate that is not issued by a valid Certification Authority. This piece of code we took it from the MSDN WCF Hands On Lab. In this piece of code we give it the CN=NAME of the certificate and it works.
Ok, we finally got it to work. This was all in development. Now we are in the testing stage and they agreed to use the piece of code that enables the certificate. The problem is that the Certificate that we need to use, after setting it in the IIS and setting it to use the famous piece of code, it doesn't work.
The error we get is this one (only showing the first part of the error and not the stack trace):
System.ServiceModel.Security.SecurityNegotiationException: Could not establish trust relationship for the SSL/TLS secure channel with authority '172.30.224.46'. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
The new Certificate is issued by their own Certification Authority, and it has several differences in comparison with our Self-Generated one, for example the "Usage" properties are different, or for example our Certificate has a "Enhanced Usage" property and theirs don't.
The other great difference we notice in the Certificate is that theirs is part of a hierarchy of Certificates, where they have a Trusted Root Certificate, then an Intermediate Certification Authoity and the Certificate to use in the Server is under that Intermediate one.
Is a special configuration needed to support this kind of certificates that are part of a hierachy? What can you guys tell us about this? .... we need some help :S
We also made a test creating a Self-Signed Certificate and all the steps needed to set it up in their environment, and the application works.
Thanks for your help and attention,
Andrey Gonzalez
Usually you get this error when the server name stored in the certificate is different from the hostname you use on the client to refer to the server.
For example, your server certificate is issued for "yourserver.com" and you are trying to access it from the client using only "yourserver" or its IP address.
In C# our maintainance project, we observered that the previous company has a root certificate. This certificate is valid in domain only, for 2020. How can they create such a root certificate free. Can anyone guide us.
Thanks in advance
Anyone can create a certificate using Makecert.exe. But it obviously won't be from a trusted authority.
You can manage certificates with certmgr.exe
I believe GoDaddy issues generic certificates (we have one here). They cost a little more, but cover the sub-domains.
If you are asking for how to do it for free. You need to set up a certificate server (or use makecert like Mitch said if you don't care about a trusted certificate), and become a certificate authority (I don't mean like GoDaddy etc., although they are one). To get people to accept the certificate, you need them to trust the authority.