| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| TLS_ECDHE cipher from Windows to Linux doesn't work |
View previous topic :: View next topic |
| Author |
Message
|
| isolom |
 Posted: Tue Dec 10, 2019 7:55 am Post subject: TLS_ECDHE cipher from Windows to Linux doesn't work |
 |
|
Newbie
Joined: 10 Dec 2019
Posts: 5
|
Hello Everyone,
we are trying to establish a TLS 1.2 connection from a Windows .NET client to 9.1 server on Linux using a TLS _ECDHE cipher. We got an TLS_RSA cipher working but none of the elliptic curve ones.
The rest of this message is technical details of what we tried. But what I would like to ask the community is this: can anyone establish such a connection? All settings possible, it just needs to be a managed client on Windows (any version), using .NET (Core or not), TLS_ECHDE cipher (any one), and on the receiving end MQ server 9.1 on Linux.
I need an understanding if it's possible. If it is, then it's on our side, and I'll keep digging. If it's not, then I'll stop wasting my time. Thank you for your attention!
We're getting 10013 in Windows Event Log, 2538 on MQ client side, and no entries in the server log.
We generated an elliptic curve certificate (ECC) and a regular RSA one with Sectigo (former Comodo). Added the cert to the Windows key repository, granted access via an HTTP utility.
Modified a SimplePut sample by IBM, compiled with .NET regular and Core libraries, tried connecting.
Modified Windows Group Policy:
gpedit.msc > Group Policy Management Console > Computer Configuration > Administrative Templates > Network > SSL Configuration Settings
double-click SSL Cipher Suite Order
and added the ciphers:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Modified the registry:
added to the registry
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETFramework\ v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETFramework\ v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Wow6432Node\ Microsoft\ .NETFramework\ v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ WOW6432Node\ Microsoft\ .NETFramework\ v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 2.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 2.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 3.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 3.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.1\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.1\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.2\ Server]
"Enabled" = dword:00000001
"DisabledByDefault" = dword:00000000
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.2\ Client]
"Enabled" = dword:00000001
"DisabledByDefault" = dword:00000000
Updated Windows security policy:
1.In Control Panel, click Administrative Tools, and then double-click Local Security Policy.
2.In Local Security Settings, expand Local Policies, and then click Security Options.
3.Under Policy in the right pane, double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing, and then click Enabled.
4. Ran gpupdate /force
Changed permissions on a folder:
C:\ ProgramData\ Microsoft\ Crypto\ RSA and grant "Network Services" Read permission to "MachineKeys" folder. Then restart server to have a try.
Granted the account running SimplePut access to the Windows key repository:
winhttpcertcfg -g -c LOCAL_MACHINE\ MY -s "computer.domain.com” -a "account"
We also opened a PMR with IBM Support and spent a year generating traces without a result. I also raised this question at the Hursley Lab summit in October without a result. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Dec 10, 2019 8:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Does it work from windows to windows?
Has it ever worked?
Does it work if you don't check for SSLPEER?
Hope it helps 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| isolom |
| Posted: Tue Dec 10, 2019 9:08 am Post subject: |
|
|
Newbie
Joined: 10 Dec 2019
Posts: 5
|
Hi,
we never tried from Windows to Windows. We assume, because there's no entry in the server log, the connection is not leaving the Windows server, and, thus, the result would be the same on other server platforms.
We also have TLS_RSA cipher working in the exact same setup. And we also have TLS_ECDHE ciphers working for JMS and Java applications in the exact same setup.
It has never worked, not even once. We don't check for SSLPEER.
Our code (it fails on the qmgr constructor):
properties = new Hashtable();
properties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
properties.Add(MQC.HOST_NAME_PROPERTY, "host");
properties.Add(MQC.PORT_PROPERTY, 1414);
properties.Add(MQC.CHANNEL_PROPERTY, "CHANNEL");
MQEnvironment.SSLKeyRepository = @"*SYSTEM";
MQEnvironment.CertificateLabel = "dotnetclientecc";
MQEnvironment.UserId = "account";
MQEnvironment.Password = "password";
MQEnvironment.SSLCipherSpec = "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384";
queueManager = new MQQueueManager(queueManagerName, properties);
queue = queueManager.AccessQueue(queueName, MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING);
message = new MQMessage();
message.WriteString("message");
queue.Put(message);
queue.Close();
queueManager.Disconnect(); |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 10, 2019 9:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| isolom wrote: |
| we never tried |
Create a test environment, and try it.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 10, 2019 6:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Does it work with an un-managed / non managed connection?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| isolom |
| Posted: Wed Dec 11, 2019 6:46 am Post subject: |
|
|
Newbie
Joined: 10 Dec 2019
Posts: 5
|
We haven't tried that either.
We are a large enterprise with tens of .NET customers. Some are packaged applications with a configuration screen, some are custom-built, some go through API, some connect from outside.
We can't switch them to un-managed, even if we prove it works. Same for Windows to Windows connections. Our enterprise infrastructure uses RHEL VMs. Proving Windows to Windows works is a waste of time. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Dec 11, 2019 7:59 am Post subject: Re: TLS_ECDHE cipher from Windows to Linux doesn't work |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| isolom wrote: |
Hello Everyone,
We also opened a PMR with IBM Support and spent a year generating traces without a result. I also raised this question at the Hursley Lab summit in October without a result. |
So in the IBM PMR, IBM had you run SSL/TLS traces and the results of the traces showed that the underlying issue is outside of the IBM MQ SSL/TLS code?
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| isolom |
| Posted: Wed Dec 11, 2019 8:40 am Post subject: |
|
|
Newbie
Joined: 10 Dec 2019
Posts: 5
|
It was determined that the issue is somewhere in the Windows security stack.
But that is understandable from the error. 10013 is thrown by the SCHANNEL - that is a Windows component. We are currently trying to find a Microsoft support person who can help us with that. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Dec 11, 2019 8:52 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Ok, sounds like you are on the right track. The only other suggestion I can think of for debugging the issue is using the Sysinternals Process Monitor tool to see if there are any clues on what is failing. I highly doubt Windows would not support ECDHE.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Dec 12, 2019 2:02 am Post subject: Re: TLS_ECDHE cipher from Windows to Linux doesn't work |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| isolom wrote: |
we are trying to establish a TLS 1.2 connection from a Windows .NET client to 9.1 server on Linux using a TLS _ECDHE cipher. We got an TLS_RSA cipher working but none of the elliptic curve ones.
The rest of this message is technical details of what we tried. But what I would like to ask the community is this: can anyone establish such a connection? All settings possible, it just needs to be a managed client on Windows (any version), using .NET (Core or not), TLS_ECHDE cipher (any one), and on the receiving end MQ server 9.1 on Linux.
I need an understanding if it's possible. If it is, then it's on our side, and I'll keep digging. If it's not, then I'll stop wasting my time. Thank you for your attention!
We're getting 10013 in Windows Event Log, 2538 on MQ client side, and no entries in the server log. |
You don't mention what level of .NET Framework. I assume it must be 4.5?
The 10013 reason code from Windows means:-
| Quote: |
WSAEACCES
10013
Permission denied.
An attempt was made to access a socket in a way forbidden by its access permissions. An example is using a broadcast address for sendto without broadcast permission being set using setsockopt(SO_BROADCAST).
Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is implemented by using the SO_EXCLUSIVEADDRUSE option. |
I'm sure you already know that of course, but it might save other readers of this thread from looking it up.
If it works with the Java client with the exact same elliptic curve certificate, then the certificates are ruled out as problematic.
If it works with RSA certificates, then the ports and firewalls are ruled out as problematic.
Which leaves the .NET support for elliptic, and the MQ use of those services.
I notice on this page in IBM Knowledge Center, that the CipherSpec that you mention is not listed as one for managed .NET client. Have you tried any of the ones listed on this page?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| isolom |
| Posted: Fri Dec 20, 2019 8:21 am Post subject: |
|
|
Newbie
Joined: 10 Dec 2019
Posts: 5
|
Thank you for your suggestions. I wasn't notified of a reply to the thread, so pardon the delay.
Windows 10 Enterprise 2016 LTSB v1607, OS build 14393.3181
.NET Core 2.1
.NET MQ Regular Client 9.1.3 CD
MQ Server 9.1.0.3 LTS
I am not a Windows person, does Core supersede Framework or include it or something else?
I tried all the ciphers on the page you suggested, no luck. |
|
| Back to top |
|
|
| RebeccaBarnes |
| Posted: Wed May 08, 2024 6:06 am Post subject: Re: TLS_ECDHE cipher from Windows to Linux doesn't work |
|
|
Newbie
Joined: 13 Jun 2022
Posts: 3
|
| isolom wrote: |
Hello Everyone,
we are trying to establish a TLS 1.2 connection from a Windows .NET client to 9.1 server on Linux using a TLS _ECDHE cipher. We got an TLS_RSA cipher working but none of the elliptic curve ones.
The rest of this message is technical details of what we tried. But what I would like to ask the community is this: can anyone establish such a connection? All settings possible, it just needs to be a managed client on Windows (any version), using .NET (Core or not), TLS_ECHDE cipher (any one), and on the receiving end MQ server 9.1 on Linux.
I need an understanding if it's possible. If it is, then it's on our side, and I'll keep digging. If it's not, then I'll stop wasting my time. Thank you for your attention!
We're getting 10013 in Windows Event Log, 2538 on MQ client side, and no entries in the server log.
We generated an elliptic curve certificate (ECC) and a regular RSA one with Sectigo (former Comodo). Added the cert to the Windows key repository, granted access via an HTTP utility.
Modified a SimplePut sample by IBM, compiled with .NET regular and Core libraries, tried connecting.
Modified Windows Group Policy:
gpedit.msc > Group Policy Management Console > Computer Configuration > Administrative Templates > Network > SSL Configuration Settings
double-click SSL Cipher Suite Order
and added the ciphers:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Also, recently I began to more actively study the topic of cryptocurrencies, namely the ?tokens vs coins? difference. I found a LOT of useful information on this subject in the article - Go to Source. Studying crypto will definitely not be superfluous, because in the future it will definitely be able to replace traditional currencies.
Modified the registry:
added to the registry
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETFramework\ v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETFramework\ v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Wow6432Node\ Microsoft\ .NETFramework\ v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ WOW6432Node\ Microsoft\ .NETFramework\ v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 2.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 2.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 3.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 3.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.1\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.1\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.2\ Server]
"Enabled" = dword:00000001
"DisabledByDefault" = dword:00000000
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.2\ Client]
"Enabled" = dword:00000001
"DisabledByDefault" = dword:00000000
Updated Windows security policy:
1.In Control Panel, click Administrative Tools, and then double-click Local Security Policy.
2.In Local Security Settings, expand Local Policies, and then click Security Options.
3.Under Policy in the right pane, double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing, and then click Enabled.
4. Ran gpupdate /force
Changed permissions on a folder:
C:\ ProgramData\ Microsoft\ Crypto\ RSA and grant "Network Services" Read permission to "MachineKeys" folder. Then restart server to have a try.
Granted the account running SimplePut access to the Windows key repository:
winhttpcertcfg -g -c LOCAL_MACHINE\ MY -s "computer.domain.com” -a "account"
We also opened a PMR with IBM Support and spent a year generating traces without a result. I also raised this question at the Hursley Lab summit in October without a result. |
It sounds like you've been through quite a journey trying to establish a TLS 1.2 connection from a Windows .NET client to a Linux server using a TLS _ECDHE cipher. You've provided a comprehensive overview of the steps you've taken and the configurations you've tried, which is helpful for understanding the context of the issue.
Given the complexity of your setup and the extensive troubleshooting you've already done, it's understandable that you're seeking assistance from the community. While I can't provide a definitive solution, I can offer some suggestions based on your description:
Review the cipher suite configuration: Double-check that the cipher suites you've configured on both the client and server side are compatible and supported by both ends. Ensure that there are no conflicts or mismatches in the cipher suite configurations.
Check for firewall or network restrictions: Confirm that there are no firewall rules or network restrictions that could be blocking the TLS handshake or communication between the client and server. Even if the TLS handshake fails, it's possible that there may be firewall logs or network traffic captures that could provide further insights into the issue.
Consult with experts: Since you've already engaged IBM Support and raised the issue at the Hursley Lab summit without success, consider reaching out to other experts or communities specializing in TLS or .NET development. They may have encountered similar challenges or have additional insights to offer.
Explore alternative approaches: If all else fails, consider exploring alternative approaches or workarounds to achieve your desired outcome. This could involve experimenting with different cipher suites, protocols, or configurations, or exploring alternative TLS implementations or libraries.
I hope these suggestions are helpful, and I wish you the best of luck in resolving your TLS connection issue. Don't hesitate to continue seeking assistance from the community, as collaboration and collective expertise often lead to breakthroughs in challenging technical issues. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed May 08, 2024 5:38 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Hi Rebecca,
You response is very generic and doesn't really add any value at all.
It almost mocks the problem analysis and solving capabilities of the experts that responded in 2019.
Why are you replying in this manner on a post that is over 4 years old?
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 08, 2024 5:50 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Reads like AI reply
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 09, 2024 5:23 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
A better reply would have been:
Create 2 channels, one with the ECC cert and one with the RSA cert.
Be aware that ciphers like TLS_ECDHE_ECDSA require an ECC certificate and ciphers with TLS_ECDHE_RSA require an RSA certificate.
So if each side has a different type of cert, you cannot agree on a common cipher_spec.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
