We are using OpenIddict, we have added Encription Certificate and Signing Certificate. The issue we have it is when the IIS restart the keys on /well-known/jwks changed, and other projects if not restart again have the wrong jwks keys, then throws 401 unauthorized. It is possible to use a fixed keys in /.well-known/jwks when the server restart?
How do you add the signing certificate? Where is it stored outside IIS?
If you use AddSigningCredential(...) and make sure the signing certificate is the same, then the JWKS keys should not change.
Solved the issue
1 -export the Certificat like a byte array
2 -use DPAPI to encrypt the byte array
3 - save encrypted byte array into a file
Then the certificate can be restored fine and the jwks doesn't change after restart
Related
I've a couple of ASP.net websites hosted on Azure and I've installed Let's Encrypt Cert for them.
When accessing one of them, although it has a valid Let's Encrypt certificate, on some customers' machines it syas the connection is not secure.
The ceriticate is definietly valid but Chrome,Firefox and Edge all say it's not secure:
What can cause this? The machine date/time is current.
The website is secure if I check it on another machine.
According to this post: https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/
R3 intermediate CA was expired on September, maybe some of the clients' trusted CAs are updated and revoked that intermediate CA.
You can use this website to validate this:
https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/
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.
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!)
I issued a self signed certificate on IIS 7.5, and it is working correctly if i access my website through my computer.
However, if i access the website from another computer, i get an warning saying the certificate was issued to another address.
Is this because the certificate was issued to localhost instead of the actual IP?
Or this doesn't make any sense?
Regards,
The error message you are getting is normal, assuming you do not have anything in your certificate aside from 'localhost' to identify the owner.
Your browser is performing a name check, and looking to validate the certificate that is presented with the URL you typed in. Typically, the common name of a certificate matches the hostname/DNS name of the machine. Alternatively, there can be information inside of the Subject Alt Name (SAN) extension of your certificate. There, you could specify multiple DNS names or IPAddress fields that identify your server in addition to the CN.
If you are simply performing internal testing, I would not be terribly worried about the warning you are receiving. Just keep all of this in mind when you move to production. Also, having your CA being self-signed, you may also receive trust warnings, unless you manually import your self-signed CA certificate into the trust store of the browser you are using.
Maybe this helps you: Self signed certificates on IIS 7. At the end of the article, in the section named "Adding the Certificate to Trusted Root Certificate Authorities", an alternative solution is shown, but it implies importing the certificate in the client machine, so that could be a huge disadvantage. However, it is a solution if you can't register the certificate on a Certificate Authority, an you have access to the client machine.
My question is about certificates specifically in ssl but I think the questions should apply to all certificates. I have included the SSL procedure for the sake of clarity.
In SSL this is what I understand the procedure is:
1)Client
sends supported crypto algorithms
sends client nonce
Server
chooses (and sends) a
symmetric algorithm
a public key algorithm
a MAC algorithm
sends it's certificate
sends server nonce
Client
verifies certificate
Extracts public key
Generates a pre-master secret key (pms)
encrypts with servers public key and sends
Client and Server
compute master secrete (MS) from PMS and nonces
PMS sliced to generate two encryption & two mac keys
Client
sends a mac of all handshakes (to ensure they were not previously modifide)
Server
sends a mac of all handshakes
Question
What stops a man in the middle attack from happening at step two? Why can't a man in the middle, say trudy, capture the certificate sent by the server and change the public key in it (to something it has the private key to).
I assume that the certificate is encrypted somehow.
However the server cannot encrypt the certificate because the client does not have the public key yet. When the server gets the key from an authority (like veri-sign) would the key be pre-encrypted using verisign's public key? I think this should work because all web browsers should have the public keys of most authorities.
No, the certificate is not encrypted. But it is signed by a certification authority (CA). Since those check the information included in the certificate (especially the URL to which the cert belongs), there shouldn't be a second valid certificate for a given URL.
The cert of the CA is checked against a trust store (e.g. in your browser). If this truststore is compromised, or if you trust not valid certificates, there is no protection against man in the middle attacks
Certificates are signed by some trusted authority, such as Verisign.
The certificates for these root authorities are built right into the browsers when you download them. You can view the root certificates in Firefox, for example, by going to tools-->options-->advanced-->encryption-->view certificates-->authorities.
If any one of these root-certificate authorities is compromised, however, you are right that a certificate could be forged, making a man-in-the-middle attack possible.
You actually pointed out a weak spot of PKI.
Say Trudy is in the middle of you and yourbank (bank.com). Trudy can change the public key at will at step 2 but the certificate's signature will be invalid. So Trudy has to find a way to generate the signature again. It's safe to say that the trusted CAs will not do this for him. So he has to sign with a fake CA, which is not trusted by your browser. This is still safe theoretically.
However, most browsers (especially IE 6) display a vague security warning and most people don't understand and just ignore, according to some tests.