I have a question about an IIS SSL certificate issue that I see repeatedly.
When I import a CA issued SSL certificate into IIS, I have found that it does NOT WORK unless I import it with the private key marked as exportable.
The default certificate import setting for every version of IIS for as long as I can remember is to mark the private-key as NOT exportable.
So if I import the certificate into IIS with private-key not exportable, web browsers like Chrome and Edge will reject it and refuse to load the web page and users get an error message.
(I confirmed the SSL certificate is the problem because the page loads correctly by enabling http/80).
I found that I have to mark the certificate as private key exportable to make it work.
Does anybody else find the same problem ?
Has anyone been able to get IIS to work correctly without the private key marked exportable ?
Why does Microsoft set the default IIS certificate import setting so that by default it DOES NOT WORK?
Does anybody know why IIS requires the private key to be marked exportable when it is installed in order to function properly?
You can install it manualy instead of using IIS Manager.
Double click the .pfx file, that will start the import wizard
Select "Local Machine" as "Store Location"
The file path will be right, just continue
Enter password and do not click "Mark Key as Exportable"
Place it in Personal store (Web Hosting may also work, had not tested)
Complete de Wizard
You can also do that using certlm.msc.
The certificate will then be available in IIS Manager and will work just fine.
If you want to use the certificate by the web server, you must export the private key along with the certificate. Without the private key, data encryption (and therefore secure communications) is not possible.
When exporting the server certificate from the server's personal certificate store, you may not have the option to export the private key. If this is the case, when the certificate was imported, the option to allow the private key to be exported may have been unchecked. This is a security measure to prevent a possible compromise of the server's private key. Since this could be a potential security risk, the option to mark the private key as exportable is not checked by default.
Make sure during the import process that you select the box "mark the private key as exportable."
Every Certificate that you install on the IIS website must have a private key associated with it. Without the private key, the certificate won't work at all - it won't be able to complete the initial SSL handshake.
Related
Is it possible to export private key from CERTIFICATE SIGNING REQUEST?
I have a CSR file and some CRT files. Now I have to install this certificate. How do I do it or do I need some other files in order to install this certificate?
No you cannot export the private key from CSR because the CSR does not contain any private key.
You need another file that has a private key and if you have that you won't need the CSR to extract the private key.
You create CSR from a private key not other way around.
In general the process goes like
You create private key
You create CSR Hand CSR to Certificate Authority aka CA
CA will give you a Certificate
you are good to go with you private key and with certificate depending upon client e.g. PHP Curl is fine with it
You may also combine your private key and Certificate using PKCS12 format depending upon your client requirements.
First comes the private key generated by you. openssl is a great utility for this.
Then the public key can be generated from the private key, or a Certificate Signing Request file can be generated which contains the public key in addition to extra information about your company and your site.
That CSR is pasted (using the Godaddy or Digicert methods) into a certificate request form on their respective sites. There is a verification process which may happen automatically or by email.
Then they'll generate a cert which you can use -- the public key is part of the cert.
So notice that you started off with a generated public private key pair, and ended with a cert private key pair.
If you're talking about a 'client' (general rule, this process can go back and forth), in general it will use just the cert, which is sent from the server during TLS (ahem, was SSL) negotiations. Or a utility program will use a cert when talking to a 'server' that is paired with it. The server is the one that will decrypt with the private key what was encrypted using the public key embedded in the cert.
So if all you have is a cert, in general you are talking about a client that knows which server it is going to go to.
But usually you are talking about a server, in which case the private key is probably already installed, and all you are doing is updating the cert. So if we are talking about a webserver, there are going to be configuration files which will point you to where the 'old' cert is that you are replacing. You'll also see where the key is, but that wouldn't need to be replaced unless you started the process by generating a new key. If so, then you'd also replace the old key with the new key.
I ended up in the same situation when I was given a new certificate from a third party for an existing CSR.
The initial CSR was complete and certificate was installed in Windows environment. When I tried to import the new certificate it was imported without its private key. This link was very helpful:
https://learn.microsoft.com/en-us/troubleshoot/iis/assign-certificate-private-key
Basically when creating a CSR (from IIS etc.) Windows stores the private key internally. When importing the certificate to the same machine, Windows automatically signs it with the private key.
When you import it for a second time. You have to use the command:
certutil -repairstore my "SerialNumber"
Where Serial number is the imported certificate's serial number
I'm stuck trying to get a WCF client to communicate to an IIS Hosted WCF Service with TransportWithMessageCredential.
In this scenario we will have about 20 clients all running the client app. It is planned they will all use the same certificate to communicate with our server to provide encryption (identification is handled separately). Our server root web site is already configured with a certificate. The WCF service will be running from a sub-site and I wish to use this same certificate to secure access from our client app to the service.
If I install a PFX certificate on the client everything is fine. But I do not want to export the Private Key from our server - wouldn't this be a security issue?
If I install a CER certificate file, run my client app, I get the error - “The private key is not present in the X.509 certificate” - sounds reasonable as I did not export one
Maybe I'm missing something; I have googled this a lot and most solutions state to export the private key.
Is there any way to use a CER certificate file without exporting the private key from our server? Or what is considered best practice.
Thanks for any advice.
I need an answer to exactly the same question...
It seems ludicrous that after going to all this trouble to encrypt things with 128 bit keys, wading through an indecipherable mess of acronyms and using prime numbers as large as my credit card balance etc etc... after all that trouble you'd go and export your private key to each and every client machine, only protected by a (possibly insecure) password on the certificate file. Crazy stuff. Pointless.
One thing to remember is that both server and client need to decrypt messages and decryption requires the private key apparently.
So they only way I can see to avoid shipping your server's private key to all and sundry is to have 2 unrelated certificates, one for the server and one for the client.
When a message is sent from client to server, the client encrypts using the server's public key only. The server then decrypts using its private key.
When a message is sent (or a reply more like) from server to client, the server encrypts using the client's public key and the client decrypts using its own private key. Voila?
At least that way the server's private key is never released outside the server. The client private key is still shipped everywhere however.
I think it then boils down to 4 scenarios that are handled with varying degrees of satisfaction -
1) Msg sent from client to server - msg encrypted using server's public key. Server cert must be available on client. Server private key does not have to be present. Would be relatively easy for a rouge client to encrypt and send a message to the server as the server's public key is readily accessible.
2) Msg received on server - msg is decrypted using server's private key. This private key only resides on the server so is pretty secure (physical security?). The server certificate containing the private key shouldn't be accessible to others unless you put a copy in a public FTP folder, or enable remote access, or something daft. And even if someone gets the server certificate, they still need to guess your brilliant password right? As an aside, I have no idea of password protected cert files can be "cracked".
3) Reply sent from server to client - msg is encrypted using client's public key. So server needs client cert (private key not needed). The client public key is again easily available everywhere, so it would be pretty easy to intercept original msg from client to server, ignore its content (as you can't decrypt it without the server's private key), and send some kind of encrypted response back to the client just to see how the client interprets it. Fun.
4) Reply from server received by the client - msg decrypted using the client's private key. This private key is on ALL client machines, in the certificate file, ONLY protected by a password... so it's relatively insecure.
Of course the other option, if you're not too worried about security, is to ship the server certificate everywhere (including server private key) and use it as both the server AND client certificate. I'm sure a lot of people do that.
This answer contains a fair bit of speculation & dot joining, as I can't find a clear explanation out there. I'd be interested to know if I've got close.
=================================================================================
Update: getting there - http://msdn.microsoft.com/en-us/library/ms733102.aspx
I am developing an html application where an user has to first login using his digital certificate. After login he has to perform encryption and decryption of data using his digital certificate.
Now in case when the certificate is available in the form of .pfx file then we can just install it and the certificate appears in the container and we can use it during login and during encryption and decryption.
This works fine in case if we have .pfx for our digital certificate.
But now i want to enhance it for etoken's(security token). I dont know much about etoken's. The problem is that how can i use the digital certificate stored in it while login?
Also how should i use the private key stored in it while decryption?
Can anyone please tell me about any tutorials (if any) which will explain the usage of etoken and the CryptoAPI's.
As I mentioned in the answer to your previous question, Windows CSPs map the certificate from hardware to Windows certificate storage, so this is transparent to you. If you can access the certificate via Windows certificate storage API, then you don't need to care where the certificate is actually located.
Note that you can't transfer a private key to the server, i.e. you would have to use a client-side module (either ActiveX or Java applet) that will perform operations locally. This is not specific to certificates on hardware, but also to certificates which have non-exportable private keys.
I'm using SharePoint 2010 and I'm configuring a web part using ChannelFactory and Certificate to access a WCF service.
But I'm getting this error message:
Error occured: Could not establish secure channel for SSL/TLS with authority 'my FQDN'.
How could I configure my SharePoint web application to have access to read this installed certificate?
(I'm sure the certificate is installed correctly on the server where sharepoint is installed and all the WCF configurations are correct)
Many thanks in advance,
Are you talking about a client certificate that SharePoint would use to authenticate itself when connecting out to some service? If that is the case, then you would need to install a certificate along with a private key. Otherwise, if you are just talking about a root certificate to validate some server certificate on a remote service, you do not need the private key.
Assuming that you mean a client certificate with private key (I don't know how SharePoint uses certificates), then you would have to install the certificate along with a private key, and then, make sure SharePoint has access to the private key.
It's not enough just to install with the private key -- you have to either install logged in as the Windows account that the code using the private key will be running under, or, if you install the certificate into the Local Machine "Personal" store, for example, you have to set an ACL on the certificate to give another Windows account access to the private key. To do that, you can use the WinHttpCertCfg tool. Cf. here for the general idea, and here to download the tool. Or from the MMC Certificate snap-in, select the certificate in the Local Machine, Personal store, right-click, select All Tasks, Manage Private Keys, and grant access from there.
Have you tried uploading it to the Manage trusts area?
http://centraladmin/_admin/ManageTrust.aspx
Rebooted the server?
Installed on all servers in the farm? Into the machine store (not service or personal)?
My use case is very simple : I have a GUI application, and inside this application I host a service however clients of this services must be able to authenticate with UserName safely (The only thing I want is to encrypt messages to be sure that nobody can sniff to retrieve password of clients, I don't care about more security).
So, I want to ship a certificate with my GUI application and that my host (which is inside the GUI application... I know it's a little dirty) use the certificate to encrypt messages.
So my question is : Does my requirements oblige me to install the certificate inside the store on the host machine ?
Am I obliged to generate a new certificate with makecert for every host ?
What is the easiest way to deploy my application ?
(I control the client application so the validation of the certificate is not a problem)
First of all you should not use makecert to generate production certificates.
You could store the certificate in code and not in the machine but keep in mind that the security of the whole encryption is as good as the security of the certificate's private key. If the machine where the application will be run is secure you could use the certificate "incode" but if you cannot guarantee the security of the host machie you should install the certificate in Windows Store. Make sure the user running the application has permissions to read the certificate's private key.
If using WSE or WCF make sure you test the default message or transport encryption methods provided to see if they are good enough for your use.
Here is some references for installing certificate with private key (.pfx file) programmaticly.