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?
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 am developing authentication through the PKI. I am new to authenticate the user through the PKI so after reading on internet i came up with this solution. A user will create a public and private key. To validate the public key the user will apply for the Digital Certificate. The Digital certificate will have the public key, the meta data of the user and the Digital Signature of the Certificate Authority. To prove no data tampering the user will use the Digital Signature which will be the hash of the certificate with the private key of the user. The user will send both the Digital Certificate, Digital Signature and the data to the server.
The server in response verify the Digital Certificate and grab the public key to validate the Digital Signature and after verification the Server will encrypt the data using Public key and send to the user. I am also using https for the secure transfer of the information.
Now I am confuse how this will be done pragmatically.
From where I can get the Digital Certificate, majorly which are the trustful CA ?
Is there any REST API by the Certificate Authority where I send the certificate to validate a certificate?
Is there any library to parse the certificate to extract the information?
Sorry I am newbie in the Digital Certificate and Digital Signature.
To prove no data tampering the user will use the Digital Signature which will be the hash of the certificate with the private key of the user.
No, the digital signature is generated over the message data using the private key. The certificate is used to verify it
The server in response verify the Digital Certificate and grab the public key to validate the Digital Signature and after verification the Server will encrypt the data using Public key and send to the user. I am also using https for the secure transfer of the information.
you should associate the public key to the user account during registration process
with https, additional encryption is redundant and useless
encryption with public key (assuming RSA) is limited to key size.
From where I can get the Digital Certificate, majorly which are the trustful CA ?
Each browser has its own trusted list. Additionally in EU exists a list of qualified certificate providers. The lists are different.
You can also build your own CA
Is there any REST API by the Certificate Authority where I send the certificate to validate a certificate?
the message format to request a certificate is standardized (pkcs # 10), but the connection protocol with the CA is not. It is possible that a CA has REST services, but in any case, a certificate will never be issued by the CA without validating the user data that is included in the certificate
Is there any library to parse the certificate to extract the information?
Of course, search for your programming language
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 am working with a REST service provider and they want me to use a client certificate provided by them when making HTTP call.
How does a client cert achieve authentication?
If someone has a copy of the client cert, they too can be authenticated right?
Does a client cert offer anything else beside authentication?
How are they different from a username/password authentication?
How does a client cert achieve authentication?
By being either signed by someone the peer trusts (including self-signing), or signed by someone that is trusted by someone the peer trusts, etc.
If someone has a copy of the client cert, they too can be authenticated right?
Wrong. They would also need the private key.
Does a client cert offer anything else beside authentication?
No.
How are they different from a username/password authentication?
Much more secure. No password-guessing is possible.
However There is no such thing as a 'client certificate provided by them'. The process of generating a client certificate starts with you. You generate a key pair and a Certificate Signing Request (CSR) and you have it signed by a CA. Or you generate a self-signed certificate. You then provide your certificate to them. If they are proposing to carry out all these steps and provide the resulting key pair and certificate to you, they do not know what they are talking about and should be severely chastised for security breaches. A private key is only private if no-one else has a copy.
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.