Error : The certificate chain was issued by an authority that is not trusted - while trying to authenticate using a certificate

[arunprakashn]

Please note that this error is the same whether I use the certificate path from a physical location or use a thumbprint that points to the store.

• The certificate is located in the windows store and the intermediate and root are also present in trusted location
• This issue is occurring only with "GoDaddy" Certificates. While using "GoDaddy" the call does not even reach the server
• When using another certificate no issued by "GoDaddy", at least the server logs indicate that the client closed the connection. It is understandable that the server should not accept this certificate but we just wanted to test it.

None of the specified endpoints were reachable      at RabbitMQ.Client.ConnectionFactory.CreateConnection(IEndpointResolver endpointResolver, String clientProvidedName)
   at RabbitMQ.Client.ConnectionFactory.CreateConnection(String clientProvidedName)
   at RabbitMQ.Client.ConnectionFactory.CreateConnection()
   at RabbitMqCertCheck.Program.Main(String[] args) in C:\Users\anagendr\source\repos\RabbitMqCertCheck\Program.cs:line 66System.AggregateException: One or more errors occurred. (Authentication failed, see inner exception.)
 ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
 ---> System.ComponentModel.Win32Exception (0x80090325): **The certificate chain was issued by an authority that is not trusted.**
   --- End of inner exception stack trace ---
   at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken)
   at RabbitMQ.Client.Impl.SslHelper.<>c__DisplayClass2_0.<TcpUpgrade>b__0(SslOption opts)
   at RabbitMQ.Client.Impl.SslHelper.TcpUpgrade(Stream tcpStream, SslOption options)
   at RabbitMQ.Client.Impl.SocketFrameHandler..ctor(AmqpTcpEndpoint endpoint, Func2 socketFactory, TimeSpan connectionTimeout, TimeSpan readTimeout, TimeSpan writeTimeout)
   at RabbitMQ.Client.Framing.Impl.IProtocolExtensions.CreateFrameHandler(IProtocol protocol, AmqpTcpEndpoint endpoint, ArrayPool1 pool, Func2 socketFactory, TimeSpan connectionTimeout, TimeSpan readTimeout, TimeSpan writeTimeout)
   at RabbitMQ.Client.ConnectionFactory.CreateFrameHandler(AmqpTcpEndpoint endpoint)
   at RabbitMQ.Client.EndpointResolverExtensions.SelectOne[T](IEndpointResolver resolver, Func2 selector)
   --- End of inner exception stack trace ---
   at RabbitMQ.Client.EndpointResolverExtensions.SelectOne[T](IEndpointResolver resolver, Func2 selector)
   at RabbitMQ.Client.Framing.Impl.AutorecoveringConnection.Init(IEndpointResolver endpoints)
   at RabbitMQ.Client.ConnectionFactory.CreateConnection(IEndpointResolver endpointResolver, String clientProvidedName)

Error when using other certificate

at RabbitMqCertCheck.Program.Main(String[] args) in C:\Users\anagendr\source\repos\RabbitMqCertCheck\Program.cs:line 66System.IO.IOException: No compatible authentication mechanism found - server offered [PLAIN]

[lukebakken]

Stack Overflow - https://stackoverflow.com/questions/76841464/error-while-authenticating-using-certificate-to-rabbitmq-using-net-sdk

@arunprakashn please notice that I have cleaned up your original issue report. In general, it's best to ATTACH files to an issue, rather than pasting a large amount of text.

I also took the time to add your code and configuration to the following GitHub repository:

https://github.com/lukebakken/rabbitmq-dotnet-client-1367

In the future, when you report issues with any software, it's polite to provide the easiest means for someone to help you, which usually is a git repository that can be cloned to access all the necessary files.

Now that I've spent quite a bit of time getting everything to the point where I can assist you, here is my initial comment -

You are using a wildcard certificate, and a certificate chain, which generally cause issues with Erlang / RabbitMQ. I will see if I can get a working example using them for you.

Since I don't have access to your certificates, I need you to run some of the troubleshooting commands from this web page (link).

On your Windows client machine, please install the OpenSSL command line tools. You can find binaries here or you can use Chocolatey or Scoop to install them. Once installed, please run these commands. Capture the FULL OUTPUT of the command you are running into a file and ATTACH the file to your response.

Please note that you will have to replace RABBITMQ_HOST and C:/PATH/TO with the actual values in your environment. The cert_01.pem file should be the wildcard certificate as well as all intermediate certificates concatenated into a single file:

openssl s_client connect RABBITMQ_HOST:5671 \
  -cert C:/PATH/TO/cert_01.pem -key C:/PATH/TO/key.pem -CAfile C:/PATH/TO/ca-bundle.pem \
  -verify 8 -verify_hostname RABBITMQ_HOST

[lukebakken]

@arunprakashn what would speed up this entire process is if you could generate a test wildcard certificate for me to use via GoDaddy, since I only have time to generate certs using the tls-gen project.

If you are able to, generate the certificate for the following CN - *.bakken.io (since I own the bakken.io domain). Please provide ALL of the intermediate certificates as well as the private key associated with the test certificate for *.bakken.io.

[lukebakken]

PS, this user experienced a lot of the same issues as you:

https://groups.google.com/g/rabbitmq-users/c/Xd9vkBXK3ww

Here is the complete code I provided to assist that person:

https://github.com/lukebakken/rabbitmq-users-dotnet-cert-auth-Xd9vkBXK3wwj

[lukebakken]

@arunprakashn v1 of my project works correctly:

https://github.com/lukebakken/rabbitmq-dotnet-client-1367/tree/rabbitmq-dotnet-client-1367-v1

Please see the README file for instructions on how to use it.

NOTE: details about this version:

• .NET application logs into RabbitMQ using guest / guest, NOT certificate authentication
• Certificates are for the localhost hostname, NOT wildcards
• There are NO intermediate certs

v2 of this project will use X509 certificate authentication. Stay tuned.

[lukebakken]

@arunprakashn v2 of the project demonstrates how to use X509 certificate authentication:

https://github.com/lukebakken/rabbitmq-dotnet-client-1367/tree/rabbitmq-dotnet-client-1367-v2

NOTE: details about this version:

• .NET application logs into RabbitMQ using X509 certificate authentication
• Certificates are for the localhost hostname, NOT wildcards
• There are NO intermediate certs

v3 of this project will use an intermediate certificate in the cert chain.

Please see this diff to see the changes between v1 and v2:

lukebakken/rabbitmq-dotnet-client-1367@rabbitmq-dotnet-client-1367-v1...rabbitmq-dotnet-client-1367-v2

[arunprakashn]

Hi @lukebakken
Thank you for your swift response. I apologize for not adding the files to a GitHub repo and thank you for cleaning it up.

I tried to add my observation to your repo but I don't have permission. I created a new repo and uploaded the observations.

https://github.com/arunprakashn/RabbitMqCertIssue

You have mentioned - "You are using a wildcard certificate, and a certificate chain, which generally causes issues with Erlang / RabbitMQ. I will see if I can get a working example using them for you."

Why should it cause an issue because its not uncommon to have a wildcard certificate with a certificate chain which usually is the case when you get a certificate issued by almost every CA. If this is a known issue, is it a defect with the SDK? If it's a defect, I need to send out an enterprise-wide bulletin that the RabbitMQ client used in my solution has inherent shortcomings with wildcard/chain and they must not use it and look at other options.

There are two more observations -

1. There is another client to the same RabbitMQ but it's a Java application running on Linux that has no problems communicating
2. This is not the first time we are connecting to this RabbitMq, it was working with a locally generated certificate without any issues, and only when we changed to a CA-generated one did it throw these errors.

[lukebakken]

I tried to add my observation to your repo but I don't have permission. I created a new repo and uploaded the observations.

Great, thank you. Using a repo for that is great. You also have the option to attach files to your comments here. Just FYI.

Why should it cause an issue because its not uncommon to have a wildcard certificate with a certificate chain which usually is the case when you get a certificate issued by almost every CA

It's just how it is with Erlang. I have been able to get wildcards with intermediate certs working in the past, but it has been a while so I'll have to refresh my memory.

If this is a known issue, is it a defect with the SDK? If it's a defect, I need to send out an enterprise-wide bulletin that the RabbitMQ client used in my solution has inherent shortcomings with wildcard/chain and they must not use it and look at other options

There's no need to do that. We'll get this figured out relatively soon, so please be patient.

[lukebakken]

OK, this output looks correct at first glance -

https://github.com/arunprakashn/RabbitMqCertIssue/blob/main/openssloutput.txt

...so that's good. Thanks for providing it.

[arunprakashn]

But there is an error code "write:errno=10054" - Just in case, you didnt notice :)

[lukebakken]

Yes, I think that's because RabbitMQ ended the connection due to the fact that the AMQP handshake was not completed.

[lukebakken]

FYI I'm working on this PR and will return to this discussion when I'm done - #1346

[lukebakken]

@arunprakashn you made the following statement in this comment:

There is another client to the same RabbitMQ but it's a Java application running on Linux that has no problems communicating

This means that RabbitMQ is configured correctly, and that you are not using the .NET / C# client correctly.

Please take the time to carefully review the V2 code I have provided:

lukebakken/rabbitmq-dotnet-client-1367@rabbitmq-dotnet-client-1367-v1...rabbitmq-dotnet-client-1367-v2

Even though it does not use wildcard certs, I think it should work in your environment. Some important points:

• I import the CA certificate via this Powershell Script. If the CA certificate is not installed correctly on your .NET client application machines, or in the wrong Cert store, the client can't verify the server certificate.
• For the client certificate, please note that a PFX file is required! (code). I created the PFX file this way: link

If you want a FAST resolution to this issue, you should provide me with GoDaddy certificates like I requested earlier in this comment. That is the BEST way for me to reproduce your environment - otherwise I'm pretty much just guessing how to get a similar set of certs.

[arunprakashn]

Hi @lukebakken

I didn't know we have to use "pfx" format. We were using "p12" and it used to work before. Not sure when this was changed. Could you please point me to the right documentation that indicates this change?

Please note that I tried both "thumbprint" and "physical path" before and the results were the same error, before raising this PR.

The below link contains the observations and results that you asked me to run.
https://github.com/arunprakashn/RabbitMqCertIssue/blob/main/Observations09Aug2023.txt

I did the below chain test using Powershell and got success. Also did the "certutil -verifystore" and that also was a success. Only RabbitMq Client says the authority is not trusted.
https://github.com/arunprakashn/RabbitMqCertIssue/blob/main/PsChainTest.txt

Regarding the certificate from GoDaddy:
I am afraid that I can provide you with those wildcard certificates as it is owned by another team in my org and I will need to raise a ticket for getting approvals for the same.

• Added my "Program.cs" in my repo for your reference

[lukebakken]

I didn't know we have to use "pfx" format. We were using "p12" and it used to work before. Not sure when this was changed. Could you please point me to the right documentation that indicates this change?

Again, this is a .NET / Windows detail. This isn't specific to the RabbitMQ.Client library. A quick google search shows that pfx and p12 are the same, so mea culpa.

Only RabbitMq Client says the authority is not trusted

That means that, if your Root CA and all intermediates are installed in the cert store correctly, the program, when run, can't access the certificate in the cert store. Usually this is a permissions issue I see with .NET code running in IIS.

[arunprakashn]

Our application runs as a Windows service usually and for testing purposes, the same exe can be run as a console application. My initial thought was the same as you that the process is unable to access the certificate in the store. I have the following reasons to believe that this is not a permissions issue.

• I ran the application as an administrator in the console mode which means it has elevated privileges and must access it.
• The same PowerShell window opened as an administrator can return success for the PowerShell and certutil commands while verifying the certificate. If they cannot access it, this must have failed too.
• Most importantly, for testing purposes, I used another certificate's thumbprint which does not have any intermediates but direct. This one does not throw the trust error. This means that the application can access the certificate store. It cannot selectively have no access to just the GoDaddy one that we are discussing.
  Certificate that does not throw this error:
  

[lukebakken]

In your screenshot, you are showing certificates in the "Personal / Certificates" store. CA certificates do not go into this store, they must go into "Trusted Root Certification Authorities". Please install all GoDaddy root and intermediate signing certificates into the correct place.

Our application runs as a Windows service

Does it run under the LocalSystem account? You should be able to start a console for that account using this technique - https://specopssoft.com/blog/how-to-become-the-local-system-account-with-psexec/

Once you do that, you can then start powershell or use some other utility to list what is in the Trusted Root cert store, to ensure all of the GoDaddy CA certs and intermediates are there.

[arunprakashn]

Attached CertNoPrivKeyExport.cer

[lukebakken]

I appreciate this, but without private keys these files are useless. I will have to figure out a way to come up with my own certs that have intermediates like yours.

[lukebakken]

@arunprakashn FYI I won't be able to return to this discussion until mid next week. Thanks and have a great weekend.

[lukebakken]

due to the fact that your program can't access the GoDaddy Root CA cert and intermediates that are stored in the Windows Cert store, or they are stored in the wrong place.

There could be another reason - you don't have these certs configured correctly for RabbitMQ to present. Please double-check that you have concatenated the entire PEM cert chain from the GoDaddy Root cert through the intermediates into the file that is configured via cacertfile in your RabbitMQ settings.

I'm pretty sure you've already done this correctly based on the openssl s_client and Java program results, but I thought I'd mention it here.

[arunprakashn]

Updated the code. https://github.com/arunprakashn/RabbitMqCertIssue/blob/main/Program-TlsSsl.cs
The status count is printed from line 32 and the following "foreach" does not print any.

Are you saying that the error that I am getting is due to the server certificate and that while validating the server certificate there are issues?
If yes, then the delegate "ValidateServerCertificate" should execute and print the details. Right?

[lukebakken]

Are you saying that the error that I am getting is due to the server certificate

Maybe, but the more likely issue is how your CA / intermediate certs are stored in the Windows Cert store and if your program can access them.

If yes, then the delegate "ValidateServerCertificate" should execute and print the details. Right?

I'm surprised we don't see that output.

Sorry I haven't had time to look into this further.

[lukebakken]

I added your code to my repository:

https://github.com/lukebakken/rabbitmq-dotnet-client-1367/blob/rabbitmq-dotnet-client-1367-v3/tlsclient/Program.cs

First, you must import the CA cert using the import-ca-certificate.ps1 script.

When I run the program against a local RabbitMQ that has been started by the run-rabbitmq.ps1 script, I see the expected output where the TLS handshake succeeds and the validation callback is called:

C:\Users\lbakken\development\lukebakken\rabbitmq-dotnet-client-1367\tlsclient [main ≡ +1 ~0 -0 !]
> dotnet run
[INFO] working directory: C:\Users\lbakken\development\lukebakken\rabbitmq-dotnet-client-1367\tlsclient
localhost
 5671
 ..\certs\client_localhost_certificate.pfx

[INFO] element Info Thumbprint: 56959DD86C2BF331608115EC0F76CCD5CB905FEA
 Friendly Name:
 Issuer: L=$$$$, CN=TLSGenSelfSignedtRootCA 2023-08-07T13:25:32.904979
 Subject O=client, CN=localhost
 Expiration 8/4/2033 1:25:34 PM
[INFO] element Info Thumbprint: AB0B197BC76B44FAA9EF2FB602055E4AD083F4B8
 Friendly Name:
 Issuer: L=$$$$, CN=TLSGenSelfSignedtRootCA 2023-08-07T13:25:32.904979
 Subject L=$$$$, CN=TLSGenSelfSignedtRootCA 2023-08-07T13:25:32.904979
 Expiration 8/4/2033 1:25:33 PM
[INFO] ChainStatus Count: 2
[INFO] chain status: RevocationStatusUnknown
[INFO] chain status information: The revocation function was unable to check revocation for the certificate.
[INFO] chain status: OfflineRevocation
[INFO] chain status information: The revocation function was unable to check revocation because the revocation server was offline.
[INFO] ValidateServerCertificate -> certificate is Valid None
[INFO] TLS client has connected successfully!

Note that I had to remove the code where you write and read data as that would cause errors since obviously it's not doing the AMQP 0.9.1 handshake correctly.

HINT - if you'd like to make changes to the code in my repo, fork it and provide pull requests.

[lukebakken]

So, I suggest you carefully modify my project to use your certs. I recommend using the same powershell script to import your GoDaddy certs.

[arunprakashn]

I made a small change to the Powershell script to import the certificate since mine is a p12 format. The import was successful though.

PS C:\OHS\testcerts> $plainText = "changeit"
$secureString = ConvertTo-SecureString $plainText -AsPlainText -Force
Import-PfxCertificate -Verbose -FilePath 'C:\OHS\certs\newlabtswildcard.p12' -CertStoreLocation cert:\CurrentUser\Root -Password $secureString
VERBOSE: Performing the operation "Import PFX certificate" on target "Item: C:\OHS\certs\newlabtswildcard.p12 Destination: Root".


   PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\Root

Thumbprint                                Subject                                                                                                                        
----------                                -------                                                                                                                        
F3BB17CB13A5BAEF6300259404E9CCC3082E1C83  CN=*.labts.net      

Results from the execution after importing and modifying your code(I have created a PR with my changes). Note that the thumbprint from my code execution matches with the import.
https://github.com/arunprakashn/rabbitmq-dotnet-client-1367/blob/mychangepatch-1/tlsclient/Program.cs

PS C:\Users\Administrator> C:\Users\Administrator\Documents\Arun\TlsSSL\net7.0\TlsSslStreamRabbitMq.exe
[INFO] working directory: C:\Users\Administrator
lab12app2.mel.labts.net
 5671
 C:\OHS\certs\newlabtswildcard.p12

[INFO] element Info Thumbprint: F3BB17CB13A5BAEF6300259404E9CCC3082E1C83
 Friendly Name:
 Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
 Subject CN=*.labts.net
 Expiration 13/02/2024 9:32:22 PM
[INFO] element Info Thumbprint: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8
 Friendly Name:
 Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
 Subject CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
 Expiration 3/05/2031 5:00:00 PM
[INFO] element Info Thumbprint: 340B2880F446FCC04E59ED33F52B3D08D6242964
 Friendly Name:
 Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
 Subject CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
 Expiration 30/05/2031 5:00:00 PM
[INFO] element Info Thumbprint: 2796BAE63F1801E277261BA0D77770028F20EEE4
 Friendly Name:
 Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
 Subject OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
 Expiration 30/06/2034 3:06:20 AM
[INFO] ChainStatus Count: 0
[ERROR] Exception Message Authentication failed, see inner exception.
Inner Exception System.ComponentModel.Win32Exception (0x80090325): The certificate chain was issued by an authority that is not trusted.
Stack Trace    at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken)
   at System.Net.Security.SslStream.AuthenticateAsClient(SslClientAuthenticationOptions sslClientAuthenticationOptions)
   at tlsclient.Program.Main(String[] args) in C:\Users\anagendr\source\repos\TlsSslStreamRabbitMq\Program.cs:line 45
PS C:\Users\Administrator>

[lukebakken]

newlabtswildcard.p12 is your server certificate. There is no need to import this into your local cert store.

What you need to import are the GoDaddy Root CA cert (which frankly should already be there) and all of the intermediates. I know you sent screenshots of them being imported but the fact remains that the client application can't access them or they are in the wrong cert store.

[lukebakken]

Hmm I wonder if you need to set TargetHost since you are using a wildcard server certificate:

https://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslclientauthenticationoptions.targethost?view=net-7.0#system-net-security-sslclientauthenticationoptions-targethost

I will add that to my code and you can update your fork.

[lukebakken]

@arunprakashn please see the changes in this commit:

lukebakken/rabbitmq-dotnet-client-1367@282e126

You can merge this into your fork. You can specify options on the command line. But, most importantly, the options passed to AuthenticateAsClient include TargetHost:

https://github.com/lukebakken/rabbitmq-dotnet-client-1367/blob/main/tlsclient/Program.cs#L85

I'm really hoping this resolves the issue in your environment. Please test it out, thanks!

[arunprakashn]

Got the same result with this code too.

PS C:\Users\Administrator\Documents\Arun\TlsSSL\net7.0> .\TlsSslStreamRabbitMq --host "lab12app2.mel.labts.net" --port 5671 --certfile "C:\\OHS\\certs\\newlabtswildcard.p12" --certpass "changeit"
[INFO] working directory: C:\Users\Administrator\Documents\Arun\TlsSSL\net7.0
[INFO] RabbitMQ host: lab12app2.mel.labts.net
[INFO] RabbitMQ port: 5671
[INFO] Client cert file: C:\OHS\certs\newlabtswildcard.p12
[INFO] element Info Thumbprint: F3BB17CB13A5BAEF6300259404E9CCC3082E1C83
Friendly Name:
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
Subject: CN=*.labts.net
Expiration:13/02/2024 9:32:22 PM
[INFO] element Info Thumbprint: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8
Friendly Name:
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
Subject: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
Expiration:3/05/2031 5:00:00 PM
[INFO] element Info Thumbprint: 340B2880F446FCC04E59ED33F52B3D08D6242964
Friendly Name:
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Subject: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
Expiration:30/05/2031 5:00:00 PM
[INFO] element Info Thumbprint: 2796BAE63F1801E277261BA0D77770028F20EEE4
Friendly Name:
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Subject: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Expiration:30/06/2034 3:06:20 AM
[INFO] ChainStatus Count: 0
[ERROR] Exception Message Authentication failed, see inner exception.
Inner Exception System.ComponentModel.Win32Exception (0x80090325): The certificate chain was issued by an authority that is not trusted.
Stack Trace    at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken)
   at System.Net.Security.SslStream.AuthenticateAsClient(SslClientAuthenticationOptions sslClientAuthenticationOptions)
   at tlsclient.Program.RootCommandHandler(String rabbitmqHost, UInt16 rabbitmqPort, FileInfo certificateFile, String certificatePassword) in C:\Users\anagendr\source\repos\TlsSslStreamRabbitMq\Program.cs:line 89
PS C:\Users\Administrator\Documents\Arun\TlsSSL\net7.0>

[lukebakken]

Alright, I'm not giving up! I will be away until Tuesday, August 29 and will return to this issue at that time.

If, in the meantime, you can generate a wildcard certificate via GoDaddy for me to use, all of this would be resolved a lot faster. A CN of *.local should suffice. Please note that I need both the public and private keys.

[lukebakken]

@arunprakashn - yesterday I went through the steps to get X509 certs from Let's Encrypt for shostakovich.bakken.io as well as *.bakken.io. I will be using those to try and reproduce what you report. Note, this is the process I used.

If I can't reproduce your issue the only other way I could help is via a Zoom session, which I'm willing to do, because this is such a bizarre issue.

[arunprakashn]

Closing this. Issue resolved.

It seems there was another "Class 2" certificate needed to validate the server certificate.
https://certs.godaddy.com/repository/gd-class2-root.cer

Once I imported this into the Trusted Root, the validation was successful.
I will be working on how the same certificate on client side gets the chain status but when presented from the server becomes untrusted and required another class2 root certificate to validate it.

[INFO] working directory: C:\Users\Administrator\Documents\Arun\TlsSSL\net7.0
[INFO] RabbitMQ host: lab12app2.mel.labts.net
[INFO] RabbitMQ port: 5671
[INFO] Client cert file: C:\OHS\certs\newlabtswildcard.p12
[INFO] element Info Thumbprint: F3BB17CB13A5BAEF6300259404E9CCC3082E1C83
Friendly Name:
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
Subject: CN=*.labts.net
Expiration:13/02/2024 9:32:22 PM
[INFO] element Info Thumbprint: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8
Friendly Name:
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
Subject: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
Expiration:3/05/2031 5:00:00 PM
[INFO] element Info Thumbprint: 340B2880F446FCC04E59ED33F52B3D08D6242964
Friendly Name:
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Subject: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
Expiration:30/05/2031 5:00:00 PM
[INFO] element Info Thumbprint: 2796BAE63F1801E277261BA0D77770028F20EEE4
Friendly Name:
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Subject: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Expiration:30/06/2034 3:06:20 AM
[INFO] ChainStatus Count: 0
[INFO] ValidateServerCertificate -> certificate is Valid! (sslPolicyErrors: None)
[INFO] TLS client has connected successfully!

[michaelklishin]

Different TLS implementations have different defaults, e.g. around how long a chain they will verify by default (yes, in some cases it can be as short as just one certificate, two is also a common value).

[lukebakken]

@arunprakashn thank you for following up!