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.
Related
Our team has a Windows 2008 server which is used primary for a common IIS dev box.
I want to enable SSL on one of the websites on IIS, so that it can only be accessed via HTTPS.
I created a self-signing certificate in IIS and installed it. However when I access the website via the browser (Chrome, Firefox or IE - doesn't matter), it always gives the scary..."this is not secure" screen. I've tried installing the certificate on my own computer, rebooting and I still get that screen.
One thing that I noticed is when I create a self-signed certificate, it adds the domain name to it...for instance, the name of the box is webIIS and our login domain is COMPANYDOMAIN. So it will say that the certificate was created by webIIS.COMPANYDOMAIN.com. This url resolves to nothing, since there is no such thing.
Am I going about it the wrong way?
I've answered a similar question here.
Few afterwords:
Your server should have a dns name. If it is in a domain (Active directory or something) it surely does. Find it, use it in CN of the SSL certificate.
CA that will issue SSL certificate should be trusted by clients accessing the server and by the server itself. Place CA certificate in Trusted Root Store (in LocalMachine store) on the server and all clients that will access it. If you have Active Directory it should be pretty simple to distribute it.
CRL that CA has to issue in defined intervals (it's up to you if the CRL will be issued one a day, month, year or lifetime) has to be accessible by clients and server. Either place it at http url that you gave when issuing SSL certificate or manually place in each certificate store (in Trusted Root Store).
In the Server
I have configured a intermediate certificate .pfx file in the IIS and created a https (443) port using binding option. I use certificate for Authorisation also I am expecting a client certificate from the client , I enabled the Require SSL and clien certificate required option in the IIS.
I checked the Intermediate certificate authorities for the root certificate and they also presents, checked the .pfx file installed in the certificate store (Local Machine) also presents.
I created .cer file from the above .pfx file with include private key option and shared the .cer file with my client and he has to attach the .cer file for authorisation .
Above is the REST wcf service with POST.
In the Client Side
I tested this application after getting the .cer file, attach that to my request in my client.exe and calling the service - it returns .403 fobidden error.
In the IIS log it is logged as 403.16 , sc-win32-status code = 2148204816 error
Please help me my above approach is correct and how to avoid this error.
Is configuring CTL is the option , or I need to get a separate client certificate for use from my client side.
You need to make small steps to debug this.
First import SSL server certificate to LocalMachine\My store. Verify
that certificate is trusted (by double-clicking it and verifying
chain).
Setup SSL binding in IIS. Verify that you can access the https site (even WCF service gives some documentation page on http/s).
Import client certificate in client CurrentUser\My store. Verify that certificate is trusted (by double-clicking it and verifying
chain).
Set SSL require mode on your WCF service on IIS. Verify that when you access https site of the WCF service a certificate is prompted and no trust error is returned (again, the documentation page should be displayed)
Server certificate must have Server Authentication extension. Client certificate must have Client Authentication extension in it. Client has to trust server certificate. Server has to trust Client certificate. This means that CRLs from both chains must be reachable.
My company has external web api service and I want to make it secure using SSL certificate. This service is called by internal application only. Is it secure to use self-signed certiifcate in IIS on production?
Yes it is secure to use a self-signed certificate even.though it is not best practice for Production environment.
Indeed the Root CA will be unknown and the client cannot validate the issuer. Your client will have to accept such a certificate (this means you will have to handle the certification check yourself)
How to ignore the certificate check when ssl
If the API is used only internally, it is not a big deal. If you have some external consumers, you should really just go and buy a certificate.
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 have created my SSL certificate using Selssl7.exe on server1 but used Cn as Server2 and hosted the certificate on server2. I started to get a certificate error when browsing from linux firefox saying:
This certificate is invalid, the certificate is not trusted and is self signed, the certificate is only valid for server1
But when I browse the URL from Windows IE I just get the regular error saying that it's not trusted and I can easily add it to exceptions.
Can we use self-signed certificates generated on server1 on a different servers?
You can and you may but you are pretty much undermining each and every aspect of authenticity by doing so.
A self-signed certificate is generally a problem because other users will not know this certificate in advance. So their browser dutifully issues a warning. That's why you have to pay for TLS certificates that will be recognized - they are issued by CAs whose certificates are contained in the default trust store of your browser. CAs had to pay to "be part of the club", but otherwise, anyone can create certificates. It's just the matter of being recognized by default settings.
But you open another hole by reusing a certificate that was issued for a dedicated server on a different server. TLS certificates' subject distinguished names must match the host name of the server they are deployed on. This is mandated by the TLS spec because this is the only effective measure to prevent man-in-the-middle attacks when using TLS. After you open a TLS connection to a server, your code will check whether the host name that you are connected to matches the subject DN of the server's certificate that was sent. Only if it does you can be sure to be talking to the right server.
So, in conclusion, if you reuse a server certificate on a different host, then you are severely impacting the security of TLS. It's still possible, sure, but if you cripple security to this extent, then you are probably better off using plain HTTP in the first place.