We configured the IIS server to require client's certificate. While we have made it work, I noticed that the IIS server is sending an Cert Authorities in the CertificationRequest. Is there a configuration in IIS to enable that?
Here is the hand shake messages:
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<Empty>
*** ServerHelloDone
The problem is if the server does not specify which CA is acceptable. The client assume all CAs are acceptable. We have multiple keys in the keystore, so the client will choose the 'first' one, where there is no definition of 'first'.
This behaviour is controlled by Registry entry: "SendTrustedIssuerList". Since Windows Server 2012 the default behaviour has changed to "OFF" by default. This entry needs be set to 1.
source: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786429(v=ws.11)?redirectedfrom=MSDN
Related
When using the rabbitmq_auth_backend_ldap, if we use ssl, is it necessary to mention SSL options to make sure we are talking to the right server, using options such as :
{ssl_options, [ {server_name_indication, "abc.com"},
{verify, verify_peer},
{depth, 5}]},
Note that I am not interested in doing client certificate authentication to the Ldap server, but only to verify whether I am actually talking to the right server, which cannot be ensured unless I verify the SN or similar from the certificate. Browsers kind of do that automatically, but how does RabbitMQ do this.
If the SSL certificate presented by the server is signed by a trusted root such as GoDaddy or such, should I still mention the certificates that I am trusting.
I verify the SN or similar from the certificate. Browsers kind of do
that automatically, but how does RabbitMQ do this.
Here is the answer to your question.
Every TLS-enabled tool and TLS implementation, including Erlang/OTP and RabbitMQ, has a way of marking a set of certificates as trusted. On Linux and other UNIX-like systems this is usually a directory administered by superusers. CA certificates in that directory will be considered trusted, and so are the certificates issued by them (such as those presented by clients). Locations of the trusted certificate directory will vary between distributions, operating systems and releases
More Info here
If you would like to have your own custom trust store. You can consider below stuff.
https://rabbitmq.docs.pivotal.io/37/rabbit-web-docs/ssl.html#keys-and-certs
https://github.com/rabbitmq/rabbitmq-trust-store
So without the below configurations, at a minimum, I feel that the SSL security is not complete for a LDAP setup.
In case of LDAP, the connection is made from the RMQ server(via erlang client) to the LDAP server, so at that point of time the SSL certificates are presented by the LDAP server.
RMQ server(client) -> LDAP server(server)
and Unless the following options are specified, the certificate is not validated.
{servers, ["abc.com"]},
{timeout, 10000},
{use_ssl, true},
{ssl_options, [ {cacertfile, "/etc/ssl/certs/ca-certificates.crt"},
{server_name_indication, "abc.com"},
{verify, verify_peer},
{depth, 5}]},
{port, 636}
verify: verify_peer
indicates that we prefer the certificate chain to be verified
will be verified that the certificate chain terminates from one of the trusted certificates mentioned in cacertfile.
cacertfile
will point to the certificates to trust.
It can be pointed to a file which contains a list of trusted
certificates in ---Begin Certificate--- ---End Certificate-- format
If the LDAP servers certificates are signed by trusted root
certifcates we can point this variable to
/etc/ssl/certs/ca-certificates.crt.
If the server certificates are self signed then point to a file
containing appropriate certificates.
server_name_indication:abc.com
this enforces that this is just not some server we are talking to but
only abc.com
will verify that the server certificates SN has abc.com.
depth:
this indicates the number of certificates in the certificate chain
that we will traverse before it needs to terminate into one of the
trusted certificates we have.
keep this a bigger number than the no of certs in your servers cert chain
This is without any client cert authentication between the LDAP server and the RMQ server.
I'm trying to send email using MailKit through provider's SMTP server using valid Let's Encrypt Authority X3 certificate. On Windows everything works great, but when sending from Ubuntu I get certificate error:
MailKit.Security.SslHandshakeException: An error occurred while attempting to establish an SSL or TLS connection.
One possibility is that you are trying to connect to a port which does not support SSL/TLS.
The other possibility is that the SSL certificate presented by the server is not trusted by the system for one or more of the following reasons:
The server is using a self-signed certificate which cannot be verified.
The local system is missing a Root or Intermediate certificate needed to verify the server's certificate. (I believe this is my problem?)
The certificate presented by the server is expired or invalid.
When I dig deeper into X509Chain status it says
RevocationStatusUnknown unable to get certificate CRL
Up until now I've been ignoring this error, but I'd rather have the underlying problem fixed and I don't know what exactly I'm missing. Thanks.
If you are running your .NET application on Mono, there's a Mono FAQ that explains how to import root certificates into your certificate store: https://www.mono-project.com/docs/faq/security/
If you are using .NET Core CLR, you might find this answer helpful: Trusted Root Certificates in DotNet Core on Linux (RHEL 7.1)
I'm using Windows Server 2012 and IIS 8.5. I've set SSL for the website and the SSL Settings are: Require Required and Require Client Certificates.
The client certificate that I'm sending to the server has been issued by a self-signed authority (let's called it MyCompany CA). MyCompany CA certificate has been successfully installed in the Local Computer Account - Trusted Root Certification Authorities. It's expiration date is 2039, so is the client certificate expiration date.
However, with all this setup, I'm getting an error 403.16 as result. I've enabled Failed Request Tracing Rules and managed to log an erroneous request and got some extra details about it:
52.- MODULE_SET_RESPONSE_ERROR_STATUS - Warning
ModuleName - IIS Web Core
Notification - BEGIN_REQUEST
HttpStatus - 403
HttpReason - Forbidden
HttpSubStatus - 16
ErrorCode - A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. (0x800b0109)
ConfigExceptionInfo
I've checked multiple sites regarding the result 403.16 and error code 0x800b0109 and all of them points to the certification authority not been installed in Local Computer - Trusted Root Certification Authorities, but that's not my case.
Thanks!
I have been working on this for a long time and finally found it!
Add a new key to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Value name: ClientAuthTrustMode
Value type: REG_DWORD
Value data: 2
Refresh the webpage, select the certificate and watch the magic happen.
Research
Using Windows 8 and IIS 8.5 I followed the instructions here http://itq.nl/testing-with-client-certificate-authentication-in-a-development-environment-on-iis-8-5/.
Certificates were created in the correct place and everything configured in IIS properly but I kept getting 403.16 errors.
After the many MSDN articles and other attempts failed I found the following registry setting.
Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Value name: ClientAuthTrustMode
Value type: REG_DWORD
Value data: 2
Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Value name: SendTrustedIssuerList
Value type: REG_DWORD
Value data: 0 (False, or delete this key entirely)
Here is some more information about this specific setting (found here: http://technet.microsoft.com/en-us/library/hh831771.aspx)
Defaults for Trust Modes
There are three Client Authentication Trust Modes supported by the Schannel provider. The trust mode controls how validation of the client’s certificate chain is performed and is a system-wide setting controlled by the REG_DWORD “ClientAuthTrustMode” under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.
0 Machine Trust (default)
Requires that the client certificate is issued by a certificate in the Trusted Issuers list.
1 Exclusive Root Trust
Requires that a client certificate chains to a root certificate contained in the caller-specified trusted issuer store. The certificate must also be issued by an issuer in the Trusted Issuers list
2 Exclusive CA Trust
Requires that a client certificate chain to either an intermediate CA certificate or root certificate in the caller-specified trusted issuer store.
For information about authentication failures due to trusted issuers configuration issues, see Knowledge Base article 280256.
Hope this work for you as well.
I have tried the solution suggested above and it works fine.
An alternative solution which doesn't involve editing the registry:
https://support.microsoft.com/en-us/help/2795828/lync-server-2013-front-end-service-cannot-start-in-windows-server-2012
The main point from this article is to remove all non-signed certificates from the Local Computer Trusted Root folder.
If you use group policies to deploy certificates, make sure that the Trusted Root Certification Authorities store only contains self-signed certificates (certificates in which the certificate property "Subject" is the same as the certificate property "Issuer"). Move any certificates that are not self-signed certificates from the Trusted Root Certification Authorities store to the Intermediate Certification Authorities store.
If you import new certificates manually, make sure that you select the
computer’s Trusted Root Certification Authorities store for the
self-signed certificates, and the computer’s Intermediate
Certification Authorities store for the certificates that are not
self-signed certificates.
You can find all the non-self signed certificates by using the Powershell script:
Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\computer_filtered.txt"
Move those certs to the Intermediate Certification Authorities folder in mmc.
I had to reboot the server to get the ClientAuthTrustMode setting to apply.
If you use IIS10 on Windows2022, TLS1.3 is turned on by default. Then maybe follwing can answer can help you: https://stackoverflow.com/a/75336463/4994931
The question is very clear but I did not find any useful tutorial online. So I wish I could have some luck here.
Basically, I want to build a client certificate authentication with Apache. I configured the conf file for Apache for the site I am hosting. The conf I put is here:
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /etc/apache2/ssl/client.crt
However I have no idea how to generate the certificate and key file for the client. And also, what file should I put on the SSLCACertificateFile in the Apache server configurations?
Does the server simply compare the certificate file sent from client with the certificate file on the server? What exactly the client certificate authentication is doing ?
You'll find instructions on how to create a CA cert and certs signed by this CA cert here:
http://pages.cs.wisc.edu/~zmiller/ca-howto/
Things go like this:
you setup your root CA key and cert
client generates his private key and certificate request
they send you the certificate request
you generate the certificate using the certificate request, your root CA cert and root CA key
you return the certificate to the client
You can then check that the client presents a certificate which is "signed" by the CA.
It is important to understand SSLVerifyClient and the other directives.
From Practical Issues with TLS Client Certificate
Authentication (page 3):
The default value none of SSLVerifyClient does
not require CCA; therefore the server will not include a
CertificateRequest message in the TLS handshake.
The value require will require CCA, and thus the
CertificateRequest message will be included in the
handshake. If the client does not provide any certificate in
the client’s Certificate message or mod_ssl fails to
verify the certificate provided, the TLS handshake will be
aborted and a fatal TLS alert message will be sent to the
client.
The value optional is the same as require, but
an empty client’s Certificate message will be tolerated.
The last possible value optional_no_ca is the same as
optional, but in addition it allows a client’s certificate to be
submitted that does not chain up to the CA trusted by the server
(because of a bug in OpenSSL [6] not yet valid or expired
non-self-signed client certificates will also be accepted).
The
value optional_no_ca can be used to perform certificate
verification at an application level or to implement PKI-less
public-key authentication that uses X.509 certificates as a
public-key transport.
I'm trying to set up client certificate authentication. I was able to generate a CA-, server- and client-certificate. As long as I use Fiddler everything works as expected. However, as soon as I start using a browser it doesn't work anymore (HTTP Error 403.7 - Forbidden).
Of course I imported the client certificate in the Personal store and I made sure Client Certificate Negotiation is enabled.
I also tried openssl s_client -connect 127.0.0.1:443 -state -debug but I couldn't really make sense of the result... The only thing what's weird is that my CA doesn't show up in the Acceptable client certificate CA names section.
Anything else I could try?
Update:
I think it doesn't matter but my server certificate is set up for 127.0.0.1. Therefore I'm using https://127.0.0.1/... in my browsers.
Update2:
Using Wireshark I noticed that my servers' response depends on the client:
Fiddler (OK):
Client Hello
Server Hello, Certificate, Server Hello Done
Browser (Not OK):
Client Hello
Server Hello, Change Cipher Spec, Encrypted Handshake Message
Update3:
After enabling clientcertnegotiation the server response is different but still doesn't work:
Server Hello, Certificate
Certificate Request
Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
My self-signed CA doesn't seem to be in the Distinguished Names list...
Update4:
SSL Settings: Checked Require SSL and Client certificates set as Required. Client cert shows up in Personal and the intended purpose is Client Authentication.
I finally found the issue and a workaround:
As mentioned in Update3, Distinguished Names doesn't contain my CA. This is because Distinguished Names has a limit of 2^14 bytes (16384 bytes). Because I do have a lot of CA installed on my machine my CA simply didn't make it in. The TLS standard would allow to send multiple messages but unfortunately Windows doesn't support this!
As mentioned here you have a few possibilities. The simplest one is this:
At your server add a DWORD (not QWORD!) value called SendTrustedIssuerList in your registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL and set it to 0. This will prevent your server from sending a list at all, letting the client choose from any installed client certificate.
Unfortunately I couldn't see any traces in the Event Viewer (as reported elsewhere). Therefore the issue wasn't easy to spot (I had to use Wireshark in order to check Distinguished Names).
Use the Accept option instead of the Require option of the "Client certificates" feature.
In IIS Manager, locate the Web application for which you want to change the SSL setting.
In Features View, double-click SSL Settings.
On the SSL Settings page, select the Accept option under Client certificates.
In the Actions pane, click Apply.
More info here
Client certificate should be imported in CurrentUser\My store with private key (i.e. p12 or pfx file usually).
CA certificate should be in LocalMachine\Root store so that IIS trusts all certificates issued by the CA and the CA is trusted for every user on the computer.
CRL issued by the CA should be either available through URL (specified in every end entity certificate that CA issued) or imported in LocalMachine\My store.
NOTE: openssl doesn't use windows certificate store so this will have no efect on openssl s_client -connect 127.0.0.1:443 -state