I am not able to authenticate my WCF service using the .cer certificate. The same service is authenticating with the .pfx certificate. The client is not willing to share the .pfx file and insists that I implement a way to use the .cer certificate. The .cer certificate I have to use is without the private key.
I have tried installing the certificate and exporting it in the .pfx format but since the .cer file is without the private key, the option to export in .pfx is disabled.
I am using the following to fetch the .pfx certificate:
((X509CertificateClaimSet)OperationContext.Current.ServiceSecurityContext.AuthorizationContext.ClaimSets[0]).X509Certificate;
I want to know if the .cer certificate can be used instead of .pfx and if through the same code, I can fetch the .cer certificate as well.
I am not able to authenticate my WCF service using the .cer certificate. The same service is authenticating with the .pfx certificate.
this is expected and by design. Authentication process requires private key, which exist in PFX and doesn't exist in .cer. Private key is used to sign authentication data and to prove certificate ownership.
The client is not willing to share the .pfx file and insists that I implement a way to use the .cer certificate.
Your client asks for impossible and potentially doesn't understand how certificate-based authentication works. There is no way to make it working with public certificate, you need a PFX with private key.
Maybe you can create your own certificate with private key and share public certificate (without private key) with client so they can install it in their app and trust it. However it depends on applications and their configurations.
Related
I would like to offer a customer a cloud service in form of a website. Now I had the idea that it would increase security enormously if this customer (several employees) also authenticated himself with a client certificate. This certificate should then be installed on his office computers and tablets. The server SSL certificate is a Letsencrypt certificate. From the client certificate I would then also know the private key, but from my point of view this is not dangerous because it is only used to authenticate against my server.
Is there a practicable solution to provide the customer with a client certificate whose public key I then store on my HTTP server?
Can I buy such client certificates from an authentication authority? Did I understand correctly that if I generate a own client certificate, the customer also has to trust my CA and this represents a security risk? Or can the customer only trust this one generated certificate and not my self signed CA/Root CA?
Thanks for anwsers
Did I understand correctly that if I generate a own client certificate, the customer also has to trust my CA and this represents a security risk?
Trusting the issuer CA of a certificate is only needed by the one who verifies the certificate, not the one who authenticates itself with the certificate. Thus in case of a client certificate only the server needs to trust the issuer CA, the client not. This also means that the client does not need to import the CA as trusted which means that there is no security risk from importing some third-party CA.
Or can the customer only trust this one generated certificate and not my self signed CA/Root CA?
The client does neither need to trust the client certificate nor its issuer CA. The client just needs to import the client certificate and the associated private key to be used as client certificate.
It is thus perfectly fine to use a private CA and let it create the client certificates for the customers. The server will then only trust this private CA for client certificate validation.
From the client certificate I would then also know the private key, but from my point of view this is not dangerous because it is only used to authenticate against my server.
Any Certificate is publicly available and only contains public key apart from other attributes and is signed by issuer CA. This can be private CA also if you only need to use certificates at organization level and not across the internet.
You may setup your private CA on your intranet and provide certificate to all Company or Organization employees. Having said this, depending on Certificate validation and revocation requirements (and your local law), you may achive PKI authentication with any Public and Private Key pair and may not require CA signed Certificate but this arrangement does not provide Certificate Revocation check and systematic PKI framework.
Refer working POC for PKI Web Authentication at PKI Authentication
This requires installing Signer.Digital Browser Extension (provided by my Company, CISPL) to be installed on clients to access User's Digital Certificate from local Certificate Store or Cryptographic device like Smartcard or USB.
The above extension also provides JavaScript API for Certificate issuance which also adds root certificate to user's trust store at the time of certificate download. You may test it at CSR Generation and Certificate Download
I hope you are doing great,
I have a question, I was wondering if it's possible to sign a CSR created with IIS, with my own CA certificate, but this one does't have any private key.
Actually I am trying to secure my WCF service with certificate authentication, and now I am configuring the IIS, to do the validations with a specific athority.
Thnks in advance.
I was wondering if it's possible to sign a CSR created with IIS
Sure.
, with my own CA certificate,
Sure.
but this one does't have any private key.
No, you can't create the signature from the CA without having the CA's private key. Otherwise there'd be no point to signatures.
I am trying to sign one of my WIX EXEs using sign tool. When I create a certificate and install it to windows certificate store, I can easily verify the EXE using sign tool. But when I try to create a PFX file and sign it, it gets signed successfully. But when I try to verify it, it throws the below error.
SignTool Error: WinVerifyTrust returned error: 0x800B010A
A certificate chain could not be built to a trusted root authority.
Number of errors: 1
I tried using a certificate chain and signing using the commands mentioned in the answer of https://social.msdn.microsoft.com/Forums/sqlserver/en-US/da5d1aef-5dbc-4400-8972-fef4d7139d99/where-windows-sdk-tools-like-cert2spcexe-and-pvk2pfxexe-go?forum=windowssdk. But that results in the same error as well. My requirement is to sign and verify using a PFX file using signtool. I cannot use Windows Store. Any help would be much appreciated.
The method described in http://msdn.microsoft.com/en-us/library/ff699202.aspx creates a self signed test certificate. A self signed test certificate is not signed by a trusted 3rd party, so you get the error "A certificate chain could not be built to a trusted root authority." when trying to verify the file signed by the certificate.
If you want to fix the error you will need to obtain a code signing certificate from a certificate authority. Usually for a fee.
When you purchase a code signing certificate, the certifying authority takes certain steps to verify your identity. If those steps are passed, the certifying authority issues you a certificate signed by their private key. Their private key is kept secret. When you verify the signed file, the verification process extracts the code signature from the signed file and validates it against one of the known public keys provided by all of the certifying authorities.
I'm reading about certificate-based authentication in SSL, and got a question about this process. (picture is taken from above link)
Question is: why server.cer and client.cer are not secrets. In this diagram, it seems that communication hasn't been encrypted when certs got exchanged, does this mean both certificates are exposed in plaintext? If so, why it's secure? Because in this way an adversary can easily obtain server's public key as well as its certificate, and impersonate the server. I think I misunderstood something. Please correct me.
Because in this way an adversary can easily obtain server's public key as well as its certificate
Correct.
and impersonate the server.
Incorrect. You need the private key as well as the certificate to impersonate the server.
The diagram you quoted isn't correct. Both sides will have not only a keystore but a truststore. The incoming certificates are checked against the local truststore; the outgoing certificate comes from the keystore.
given that the certificate is used to verify the public key belongs to the server
No. The certificate plus its digital signature is used to verify that the certificate belongs to the server. The digital signature is created with the private key. See the article you quoted.
However it isn't entirely correct. In the diagram, incoming certificates are checked against a local truststore, which is separate from the keystore. The session key is never exchanged (2.1 step 5).
Firstly, Thanks to all those patient techies trying to help unknown people.
Secondly, I have a wcf service which should be consumed by only several clients (10) known to our company. This wcf service has the x509certificate "CN=ABCD". Now it expects to receive a certificate in turn from clients to consume this service. So here are the design questions
Should I create one certificate
"CN=ABCD" , then right click on it
and export as pfx files and
distribute them to Clients?
Some say to validate in code and
some say to validate in config which
is better?
How should I know which client is
calling as the certificate has same
name for all if my company
distributes it?
what is the difference between .cer
file and .pfx file?
When passing the certificate to
clients, will I be giving both .cer
and .pfx files?
How should I be revocing only one
client if it expires?
My comapny already has a certificate
like *.fdfd.org . Can I use this as
my X509Certificate instead of
generating one?
Many questions! But due to lot frustration, I wanted to have the opinion of developers out there because I couldn't get the right info.
NO You must have separate certificate for the service and you should have one certificate for each client. Once you share private key of your service your security has gone.
You can either install public keys of client certificates to Machine\Trusted people (client with any trusted certificate will have access to your service) or you can use custom certificate validator (only message security - according to your previous question you probably use message security) to validate really only those 10 certificates.
This is only possible if you create separate certificate for each client. It is also possible to combine certificate with supporting user name and password but it requires very advanced WCF configuration and still sharing single certificate among multiple clients is a bad decision.
Certificate is just container for some information - keys for asymmetric encryption. .cer contains only public key which can be freely distributed - you will probably have to distribute .cer file of your service's certificate among clients. .pfx contains both public and private key and must be secured as much as possible. Once .pfx file is compromised the certificate is not secured any more and must be replaced. Because of that you must keep your service's .pfx (installed in certificate credential store) and each client must keep his .pfx.
If you create certificate for clients you will pass at least .pfx to them. Obviously once you send such certificate by unsecured email you seriously hurt the security.
If one client expires you will remove its certificate from trusted certificates. If you have your own certification authority (which you should have if you want to create certificates for clients)
If your service sits on fdfd.org you can probably use it but only for the service.