How do I add a Connected Service that requires a Certificate?
I need to call a SOAP API developed by another company. The company has supplied me with a pfx-file based on a cer-file I've created. I've installed the certificate in "Trusted Root Certification Authorities" (in local computer and current user) using the supplied password. But when i try to add a WCF Web Service Provider either through the URL or the wsdl-file I get the error: "Could not create SSL/TLS secure channel", and the addition of the service is abandoned.
When I contacted the company they asked me to check if the certificate was installed correctly by calling the API from SOAP UI (adding a jks-file they gave me) - this works fine. They could not be of further assistance.
I'm writing a aps.net core web application and using .net core 3.0 in VS19
I'll have to mention that this is my first practical encounter with certificates and the question might be somewhat in concise.
The PFX might contain more than one certificate.
Are you shure you created a .cer (Certificate) and not a .csr (Certificate signing request)?
Nonetheless, the certificate must be in the personal store and the the certificate that issued it must be place into the Trusted Root Certification Authorities (if it is the last one in the chain).
Here is an example ( i ran certlm.msc and clicked the end entity certificate:
Sectico is the root certificate and goes to Trusted Root Certification Authorities
COMODO RSA ... is the intermediate certificate and goes to Intermediate Certification Authorities
Daniel... is the end entity certificate and goes to Personal
I recommend to import into Personal and then move (drag-drop) the certificates.
For the end entity there must be a private key associated - which can be identified by the key icon:
Microsoft also provides some documentation on the topic: https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff648360(v=pandp.10)?redirectedfrom=MSDN
Related
I am working on a client-server application where server is a web server which performs client validation based on SSL certificate. Server trust a Root CA certificate. Client is a windows application developed in C++ which has a certificate signed by intermediate CA which in turn signed by Root CA.
I am able to set client certificate during https connection by calling WinHttpSetOption api with WINHTTP_OPTION_CLIENT_CERT_CONTEXT as option. However this will set only client certificate but not the entire chain. Server does not have intermediate CA in its store hence it is not able to authenticate the client.
Is there a way to set the full client certificate chain in WinHttp, provided the full chain is already present in certificate store of client?
The server has to have the CA certificate beforehand, it's not going to trust the root CA the client hands it. (I'm not sure about whether it (the server-side) would trust an intermediate CA signed by a trusted CA but my inclination says no).
Trusting some random CA a client sends would break the entire point of certificate verification, you would have no idea of whether the data the client submits is actually meaningful. So add the root and intermediate CA certificates to the server's certificate stores. (If you don't have access to that you'll have to talk to an admin and have them do it).
I'm not really seeing anything wrong with what you are doing.
You are implementing mTLS. The client side has a private key that it uses to validate itself to the Server. Most times the client will generate this private key itself and just send it to the server via CSR. In your case you have some CA generate it for you.
mTLS is used in place of some other sort of login a client might do to a server. The client itself doesnt care about the cert chain. The client doesnt need to validate itself. It just sends a token encoded via its private key. The server DOES need the root or intermediate cert in order to validate the key the client has sent. Usually you just install this root into your normal cert store (server side) so the server can validate the client.
Only I could find was to Add Sub CA to system store. During service startup or installation, open the CA certificate store and Add certificate context to it.
I developed a web service to be consumed by another team.
These were my steps:
developed a web service with jax-ws 2.2.8 and jdk 1.7
deployed the web service to run on Tomcat 7
generated the client classes
created a self-signed server certificate using the jdk's keytool
configured Tomcat to support SSL connection
exported the generated server certificate to a certificate file
imported the server certificate into the truststore file
specified CONFIDENTIAL transport-guarantee in web.xml for the web service's servlet
developed a test client to consume the web service using the client classes
So then the other team started working with it and I was informed that the certificate is not properly signed. Is a self-signed certificate improperly signed? Is that true? I didn't think so. Well I don't want to argue the point. I was informed that they have their own signing authority that is already trusted by most of their system and it was suggested to me that I replace my cert with the one that is signed by the certs displayed in two screenshots that I was provided. I wasn't provided any further information but I guessed the screenshots were taken in Internet Explorer, Tools, Internet Options, Content, Certificates, Intermediate Certification Authorities, then in the list I found a certificate and clicked on View, clicked on Certification Path and my screen matches the screen of the other team member with one exception. His screen displays:
Company Name Root CA
Company Name Issuing CA
teamname.companyname.com
Whereas my screen only displays:
Company Name Root CA
Company Name Issuing CA
I don't see the
team.companyname.com
on my screen and not too sure how that got there or if I need that.
Then I clicked on Details and compared Version, Serial number, Signature algorithm, Signature hash algorithm, Issuer, Valid from, Valid To, Subject and Public key and they are all the same. The rest of the fields are not visible in the screenshot.
So where do I go from here? I am not certain.
According to: Apache Tomcat 7 documentation, Tomcat operates only on JKS, PKCS11 or PKCS12 format keystores.
My questions are these:
1) Should I export the certificate using the Certificate Export Wizard? (I am using Windows 7)
2) If so, should I select the format Personal Information Exchange - PKCS #12 (.PFX)?
3) And if so, which of the following options need to be selected?
Include all certificates in the certification path if possible
Delete the private key if the export is successful
Export all extended properties
Wait! Hold on! I just tried to select Personal Information Exchange - PKCS #12 and it is disabled. Hmmm.
Is there a way to export the certificate from the browser for the purposes of somehow getting a keystore format supported by Tomcat? And I must add that I don't know how to get from point a to point b and any help would be appreciated. And it also concerns me that my certificate doesn't display:
teamname.companyname.com
in
Company Name Root CA
Company Name Issuing CA
teamname.companyname.com
Any ideas/suggestions/feedback would be greatly appreciated as I not too familiar with certificates!
None of the above.
You need to follow the same steps you used to create your self-signed certificate but after you have created your Certificate Signing Request (CSR) you need to give that to the other team to get them to sign it with their Certificate Authority (CA). Then you continue as you did before.
I have a simple question (maybe stupid) and i didn't find any clear answer to it. If i get a certificate from a trusted signing company (like verisign...) for one of my server (web for instance), i'll have private an public keys. With this certificate can i set up my own intermediate CA and sign cert request and the be trusted by every one (i know that's shouldn't be..)? My real question is : what will prevent me for issuing certificate and how the company can garanty that nobody does ??
Thanking in advance!
The certificate issued for your web site is suitable for SSL/TLS and is not suitable for issuing other certificates (Key Usage field is different). Consequently while you technically can generate another certificate using yours as a CA, such generated certificate won't be trusted by properly implemented and configured validators (those that check Key Usage).
You are not paying verisign or other certificate organisation for the certificate publishing but for the certificate validation, this meens that they have web services that respond if your certificate is valid or not, if it is still active and not expired and your contact information as requested.
Unfortunatly this is something you have to live with it and pay them if you really need ssl over your site.
I have used a homemade certificate for my lan server and when i visit this https site a big red warning notifies me that this site is malicious and it has not a valid certificate. This doesn't bother me but I am sure that all of my clients would have freeked out if they see such a bold warning popping up to their browser.
what can you do? it's a companies' world
Linked to my question about client certificate authentication done the right way I was wondering whether I have to take the step to link a certificate to a user (active directory or local user) in order to have clientcertificate authentication to work as expected?
And is it necessary to disable all other authentication schemes (anonymous, windows) for clientcerticate authentication to happen?
See this question on the IIS forum:
This is what I would like to achieve:
A SSL-certificate for the URL itself (https://example.company.com). To my understanding this certificate does not have any connection whatsoever to client certificates.
Client certificates issued from my local CA and shared to trusted clients.
Some way of specifying which client certificates are allowed to connect to a specific IIS web site.
3 seems... complicated, to say the least. If I just set everything up and connect with a client certificate I have issued it works. The CA and the web server are on the same domain (if that matters), and I have added the root certificate from the CA to the trusted CAs on the web server. However, at this stage I have not told the web server which client certificates to accept, so my first guess was that it accepts all client certificates [chained to] any CA it trusts.
See also this question, which links to this site, which is dead.
It comes down to creating a "Certificate Trust List", or to mapping certificates to user accounts.
You can however implement a custom certificate validator in your service, how to do so is explained here.
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.