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
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 have the following use case:
A client sends its certificate to my portal.
My portal needs to authenticate the client based on the certificate.
The certificate sent by the client could be signed by a known Certificate Authority or could be signed by a Certificate Authority which is specific to the client's organization.
My portal would, in some way or other, be able to get the public key of the Certificate Authority if the client's certificate are signed by the client's organization.
Could you please suggest me ways to implement this use case using OpenAM?
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
If I use SSL for my app to communicate with my server, can I use any SSL certificate, like those issued by goDaddy? I understand the reason people buy Verisign certificates(which are terribly expensive) is that they are supported by all browsers. But if I have no browser component, and the communication is between my app and my services, can I go for a cheaper one?
How SSL works
The Goal of SSL Certificates is to ensure no Man In the Middle is earsdropping on your encrypted communication. When your app is connecting to your server, your server therefore presents a certificate which tells, that the used encryption key really belongs to your server. This certificate is cryptographicly signed by a trusted party, such that the man in the middle can not forge such a certiifcate. Your app has to know the cryptographic key of the trusted party in advance to verify this signature.
Use godaddy certificates
You can use any certificate made by a trusted party which is known by your app. If you include the godaddy cryptographic key (called root certificate) in your app you can use godaddy certificates.
Use your own zero cost certificate
For you and your app, you yourself can be a trusted party for certificate signing. You can use your own self generated certificate without paying anyone for it. You only need to include your own certificate in your app. You can find a tutorial on how to generate a self signed certificate at http://www.akadia.com/services/ssh_test_certificate.html .
We have a proprietary framework and now we want to integrate the authentication by client side ssl certificates.
What are the best practices to map a client certificate to a proprietary user account (for example a simple user table in the database)?
Save to public key of the certificate?
Save issuer and serialnumber?
Or are there other possibilities?
Are you issuing the certificates (and have a possibility to set some fields of the certificate)? Does these certificates have to be integrated with a larger scale PKI environment like email-signing (I mean have you the X.509 interoperability nightmare)?
If you can create a certificate authority for the users, and have not to care about foreign systems, you can give each client certificate a common name attribute which maps directly to your user account. So you can check if the client certificate is signed by the user certificate authority and then match the certificate CN attribute.
When there is only a limited and well known number of signing certificates then I recommend to store this certificates and check the client certificates and accept them only if they are signed by one of the signing certificates. Then you use a field of the certificate which the issuing CA sets uniquely for each user (which stays equal when the user certificate gets renewed, many cooperations let user certificates time out after about one year) to connect this field with your user database.
If you can't issue the certificates you can store the hash of the certificate in the database, but this has the drawback that when a certificate runs out of date you need to update the database. The hash is unique to each certificate, while the most fields of a certificate can be spoofed.
You may also want to check the certificate revocation lists for the signing certificate authorities, so no user can access your service with a stolen certificate.
We store the client certificate's serial and issuer DN and match it. According to http://www.tectia.com/manuals/server-admin/60/userauth-cert.html, this is enough to uniquely identify the certificate.