I bougth a SSL certificate online from a seller today for my custom domain which redirected to the azure web application with cname.
I did created csr file with that domain let's call it app3.product.com by using IIS 8.And then created the .crt filel with that csr file.
After that i did found that i need the pfx file but i didn't have .key file so, i converted the .crt to .cer than uploaded it by azure portal.
The problem is Azure portal says,
No certificates match the selected hostname
Althogh my certificate issued as app3.product.com and the host name has the same domain name. It doesn't work.
I didn't include key file while i am creating the csr file also the subject of the certificate has some additional information by the issuer. The subject like app3.product.com, Certificate Issued By ... These may be the source of the issue.
Thank you in advance.
You need to include the private key. Otherwise your web server can not decrypt the data the clients (web browsers) are sending to it.
Explanation:
HTTPS/TLS/SSL are based on asymmetric cryptography which means that data gets encrypted with a so-called public key and can only be decrypted with the corresponding private key.
This means that your web server will send a certificate to the browsers which contains the domain name + the public key + a signature from a Certificate Authority (CA). The web browser then checks then if this certificate is valid (with a CA certificate) and uses the included public key to encrypt further data. Since your web server is the only one who knows the private key it can use it to decrypt the web browsers request. Actually the overall process is even a little bit more complex. You might want to have a look at the TLS handshake protocol to see how it works.
Related
I am implementing mutual authentication between a single client hosted app (CLIENT) and my spring boot 2 application (SERVER). I understand the steps to be as follows:
The server generates a keystore and truststore. The keystore being used for storing the server's certificates and private key. The truststore used for storing other credentials (certificates from certificate authority (CA) or trusted client certificates).
A CSR is raised for the server which is then passed to a CA. The CA generates a signed certificate from the CSR. This is the installed in the server keystore.
The client (which has it's own keystore and truststore) provides their public key to the server. This is then installed in the server truststore.
When a https request is made from client to server:
The client makes a request to access a protected resource.
Server responds with their public certificate.
Client verifies that certificate (looks in truststore and checks if it signed by a trusted CA).
Client presents their public certificate to server.
Server then verifies certificate against their truststore.
Assuming verification success client is granted access to the protected resource.
So I have a few things which I'm a bit confused about...
Are the steps outlined above broadly correct?
How does the server verify the client certificate? (I think it looks at the truststore for that certificate but not sure what actually happens after that).
I've seen examples of the CA certificate being installed in the server truststore instead of the actual client's public certificate ~ is there a use case when this should or should not be done? For my use case I have been provided with a signed certificate from the client (third party). The CA who signed that is different from the CA who signed the server certificate.
Does this process actually authenticate the client i.e. this client can now have access to the servers protected resources but another client who might present a different certificate will not have access? (like a more secure method of providing a username and password)
Where does common name (CN) checking come into all of this? I note in Spring Boot X.509 you can derive a username from the CN and then use this to lookup the appropriate user details from the user details service.
If the client certificate gets compromised for whatever reasons is this managed by just removing it from the server's truststore?
Is there an advantage, in my scenario of using a trusted CA e.g. verisign to produce a client certificate over a self-signed one? i.e. the certificate is passed to me directly from the trusted third party, and then installed.
In respect to your first question, yes your outlined steps are correct! Here is the general mutualSSL flow with a graphical overview: (source)
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
Your second question (How does the server verify the clients certificate?):
The server verifies the clients certificate with the help of the signature. The signature is usually a hash-value, build of the complete certificate. The hash-value is signed with the private key of a corresponding CA (certificate authority). The server verifies the signature of the client certificate with the help of the CA's public certificate.
Your third question (Servers truststore containing the clients public key/certificate or the corresponding CA certificate?):
If you use for example self-signed certificates, you probably have to import the clients public key/certificate directly into the servers truststore. If your client uses an CA signed certificate, it is appropriate for you server to store the CA public key/certificate only, because it is used to verify the clients certificate.
Your fourth question (Does this process actually authenticate the client): Yes! As you can see in the answer to your second question, the certificate is verified by checking the signature. The signature is a hash over the complete certificate. A standard X.509 contains information to identify the subject. By checking the signature the subject is authenticated. A standard X.509 certificate contains amongst other things e.g. this information:
Subject name, Subject Public Key Info, Public Key Algorithm, Issuer Unique Identifier (optional), ...
Your fifth question (Where comes CN checking?): The CN (common name) verification is executed during the certificate check. The CN identifies the valid hostname for the current certificate. It is limited to one entry. As an extension the SAN (subject alternative name) was introduced. A certificate can contain more than one SAN. The CN (and the SAN) entry is part of the certificate and is verified with the help of the certificates signature check.
Your sixth question (If the client certificate gets compromised for whatever reasons is this managed by just removing it from the server's truststore?): Therefore the CAs use so called revocation lists. If you are using for example self-signed certificates it would also be okay to just remove the compromised certificate entry from the servers truststore.
Your seventh question (Is there an advantage, in my scenario of using a trusted CA e.g. verisign to produce a client certificate over a self-signed one?): There exist a few advantages of using a CA signed certificate instead of self-signed ones.
The certificate and eventually the revocation is managed by the CA
The certificate is valid to every relying party of the public CA, e.g. Verisign
Most of the public CAs offer standardized ways of creating a certificate
My web host is shutting down - as they have been bought out. I am having difficulty getting my SSL certificate from them.. I am on my 3rd attempt and I have managed to get 2 files.. one I believe is the initial CSR, the Other is my Private Key .KEY file (although the Hosting Provider has been giving me them and claiming they are .crt - they are not) - that would be my actual Certificate!
I have my CSR file which is headed by -----BEGIN CERTIFICATE REQUEST-----, I have my Private KEY file which is headed by -----BEGIN RSA PRIVATE KEY-----
Is there any way fro me to use both of these components to produce my .crt file - I am not sure if my hosting provider (what is left of their support team ) knows the difference between these three files. Of course I am certainly learning myself. I had just purchased that cert from them about 4 months ago and I need it.
So is there any way I can use my two files .CSR and .KEY to generate
my .crt file ?
There is no way to re-create your certificate from the private key and certificate signing request (CSR), unless the certificate was self-signed. However, if the website is still up you can simply connect to the website with various tools and retrieve the certificate that way. Make sure you also retrieve any intermediate certificates as well, although these can almost certainly be obtained from your certificate authority (CA) website as well.
I would like to know what are the exact steps of certificate authentication over HTTP.
I know this has been asked before, but from what I've read it's still unclear to me how it works.
When first contacting the secure site client will send its certificate
This will be his public key ( let's say a public_key.pem file begginging with ----BEGIN PUBLIC KEY---- )
Server will look whether this certificate has been signed by a trusted CA.
The server only has a list of certificates which it trusts (you configure this keystore when configuring SSL). That is where all private keys are stored. Is this equivalent to all the trusted CAs of the server?
The next step now is to take the public_key.pem and check whether any of the certificates in the keystore have signed it.
If the above process is accurate:
First question: A 'certificate' is a private key signed by another certificate ( or self-signed )
Second question: How exactly does a server validate that a public key was signed with a specific private key ( certificate ) ?
Third question: 'certificate' A can be used to sign another 'certificate' B, consequently 'certificate' B can be used to sign certificate C and so on. If my server has certificate A in its truststore, it means it will also trust public keys coming from certificate B and C ?
Edit based on answer below
My server has cert.pem and privkey.pem. The cert.pem ( x509 certificate ) has been signed by a trusted CA using its private key ( the 'signing' process involves the CA to do 'something' with its private key and sign my Certificate signing request ).
When SSL is negotiatied my server will send the cert.pem to the client ( in some form ). How does the client determine that my public cert was signed by a trusted CA. My truststore pb only contains other public certificates of trusted CAs, so it ends up checking whether my cert.pem was signed using only public certificates of trusted CAs.
This is is the part which is unclear - and I may be missunderstanding the whole process - can a client check if my x509 certificate is valid by just having an x509 list of certificates of trusted CAs?
When first contacting the secure site client will send its certificate
A client doesn't have to send a certificate. Judging from your question, it doesn't sound like you're asking specifically about client-cerificate authentication. In many sites, like if you go to google, stackoverflow, facebook, etc, the client / browser will not send a certificate.
A 'certificate' is a private key signed by another certificate ( or self-signed )
Not quite. A certificate contains a public key that is signed by the private key that corresponds to another certificate.
I think this is worth clearing up. A certificate itself will only ever contain the public key, or the "Subject Public Key Info" in x509 parlance. There is a corresponding private key to that public key that is stored separately from the x509 certificate.
There are some formats that "combine" the certificate and the private key in to a single file, but at this point it isn't a certificate anymore, it's a file containing a certificate - an example of this is PKCS#12. This is a format that can store as many certificates and private keys as needed.
A private key may not even necessarily be a file on disk - it could be in a Hardware Security Module, SmartCard, etc.
'certificate' A can be used to sign another 'certificate' B, consequently 'certificate' B can be used to sign certificate C and so on. If my server has certificate A in its truststore, it means it will also trust public keys coming from certificate B and C ?
Yes. This is called a certificate chain. A is the "root" certificate, B is an "intermediate", and C would be an "end-entity" or "leaf" certificate.
This is very common among HTTPS certificates by CAs. Certificates are never issued directly off the root, they're issued off the intermediate.
How exactly does a server validate that a public key was signed with a specific private key ( certificate ) ?
Well this makes the assumption that a certificate is a private key, which it isn't.
The server, as in the thing serving HTTPS, doesn't really care about the validity of the certificate. It's up to the client to decide if it should trust the certificate the server gives.
The server has the certificate and the corresponding private key. The server can validate that the public key and the private key belong together. How this is done depends on the key type, but the gist of it is, if you know the private key, you can fully reconstruct the public key from it. The server will validate that the private key's "public parts" match the certificate's public key.
The server will present the certificate to the client, like a browser. The browser will check many things, but at minimum it will check two important things:
Can the browser build a chain back to a certificate in the trust store. So the browser will look at the signer of the certificate, called the Issuer, and check if the issuer is in it's trust store. If yes, then the certificate is trusted. If no, it will see if that certificate has an Issuer, and loop all the way down the chain until it reaches the end of the chain, or when it finds something in the trust store. If it reaches the end, then the certificate was not issued by anyone it trusts.
That the certificate is valid for that domain. The certificate contains a Subject Alternative Name (SAN) which indicates what domains the certificate is valid for.
There are lots of other things that get checked, like expiration, revocation, Certificate Transparency, "strength" of the certificate - too many to list.
How does the client determine that my public cert was signed by a trusted CA.
Every client has its own trust store. Internet Explorer on Windows uses the Windows trust store, Google Chrome on macOS and Windows use the operating system trust store (Keychain, Windows Trust Store, etc).
The browser / client needs to build a trust path, as described above. How it does this is a bit complex, but it works out to the Authority Key ID attribute - if it exists, and the Issuer property of the certificate. It uses these values to find the certificate that issued it.
Once it finds the issuing certificate, it checks the signature on the certificate with the issuer's certificate public key.
That issuing certificate could be in the "root" trust store, and uses the public key in the issuing certificate to verify the signed certificate.
Your web server might (probably) send intermediate certificates along with the "main" (leaf) certificate. The client might use these intermediates to build a path back to a certificate that is in the root trust store. Intermediates can only be used as intermediates - you can't send an additional certificate saying "here's the root certificate, trust it".
can a client check if my x509 certificate is valid by just having an x509 list of certificates of trusted CAs?
Yes. That is the trust store. Every browser has / uses one. Firefox has their own trust store called NSS. Operating systems typically have their own trust store, too.
I have website hosted on IIS. My main issue is that I want only users with a specific certificate installed to be able to access the site. I tried to follow some tutorials but I can't find anyone covering both server and client side, since I can't get it to work.
I have some questions to the main issue:
What kind of certificate should I use (domain/selfed signed in IIS 7.5)? I do have access to a Active Directory Certificate Services where I can create other types of certificates (CA), but the problem is when trying to import them to my IIS ("certificate cannot be used as an ssl server certificate")
I would like to use a CA certificate, but is that possible when using IIS? Or do I need to write all the code the check if the user has the right certificate?
When created a certificate for the website (e.g. though IIS)..How do I create user certificates that are trusted by the server certificate?
As you may noticed by now I'm not sure how to do all of this, and would really like some help..
Server should use SSL server certificate. This certificate has to have Server Authentication extension in Extended key usage. Server certificate should have SAN extension (Subject alternative name) with domain name of server as DNS name (i.e. somesite.com)
CA certificate has to be imported to Trusted root store (preferably Local Machine) on both server and client machines.
Client certificate should contain Client Authentication extension in Extended key usage.
All EndEntity (client and server) certificates should have CRL distribution point in them where there is URL to CRL that is issued by CA. CRL has to be accessible by both client and server and should be always valid.
You can use XCA for training purposes. It has a nice GUI and it has templates for CA, SSL server and SSL client certificates by default. Then you can mimic these certificates in your Active Directory Certificate Services. Documentation and some guides can be found here.
I'm new to mutual SSL. Therefore my understanding how client certifcates might be wrong.
When using Client certificates in IIS, do they need to be issued from the same certificate (or CA) as the IIS HTTPS binding has configured?
My dev IIS has a self signed certificate.
For the client certificate, I've created a CA and a Client certificate according to
the post here.
The CA is in my "Trusted Root Certification Authorities" of the local Computer.
The Client certificate is in my personal certificate folder.
On IIS I've set Client certificates to accept.
The first strange Thing is that when I browse to my page, the IE always shows me 403.7. Even I've disabled the IE setting "Don't prompt for client certificate selection...", there is no window opening for the certificate selection.
Also when accessing the page with a HttpWebRequest with Client cert attached, the response is always 403. Unfortunately there I did not figure out how to get the sub status.
Why doesn't IIS accept my Client certificate when the RootCA of the Client certificate is in the trusted root store?
Is there a way to get more details where the problem might be?
Thanks
Thomas
Finally could solve the issue:
The CA and Client certificates which I generated according to the tutorial here did NOT have the private key assigned in the certificate store. I had to remove the certificates from the cert store and Import the PFX file including the private key.
Second, the client certificate needs to be in the Current User/Personal store so IE does pick it up. I initallly generated it in the Current Computer/Personal store.
There might be a direct way how to create the two certificates including Private key with makecert. But the PFX import was the easiest way for me.
After 3 days of try and error on my side: If you use IIS10 on Windows2022, TLS1.3 is turned on by default.
The SSL handshake seems not to be implemented correctly in browsers/curls/.... for this case.
For testing reasons turn off TLS1.3
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server
Add:
DisabledByDefault as Dword with 1 and restart the server (not only IIS!)