And it look like it is serving a good certificate
https://www.ssllabs.com/ssltest/analyze.html?d=la.www4.irs.gov&s=23.211.139.199
4 Likes
Latest response from them.
ISRG (from Root.cer) does belong under Trusted Root Certification Authorities,
but la.www4.irs.gov (from ServerCertificate.cer) doesnât (itâs not any kind of a CA).
Intermediate.cer belongs under Intermediate Certification Authorities.
ServerCertificate.cer may not need to be added at all, but if it is needed it belongs under Other People or Other Devices (or conceivably Trusted People).
It should NOT be in either of the two âCertification Authoritiesâ classes, since its extensions make it illegal as a CA.
So @jamiebray,
Can you provide more details on the actual issue that is happening?
Possibly a diagram showing your client talking to their server.
What is the client application you are using?
Please show logs and errors being displayed.
4 Likes
The intermediate certificate is send by the server and is not needed on the clients system.
Further more, I agree with Bruce.. Can you please please please explain in simple words what you're actually trying to do to exactly which hostname on which port and HOW you try to do that. And please provide screenshots or something like that so we can understand better. Because now I feel it's one chaotic thread and I'm having a hard time understanding.
3 Likes
App is a company built app we've been using for several years, we update it every year for new season changes, this happened out of the blue when they changed cert stuff on their end and now our app gets this every time.
Service Exception
----------------ServiceException Detail ----------------
Declaring Type : System.Runtime.Remoting.Proxies.RealProxy
Message : Could not establish secure channel for SSL/TLS with authority 'la.www4.irs.gov'.
Source : mscorlib
Method : HandleReturnMessage
Date : 10/18/2024
Time : 12:32:46 PM
Error : Could not establish secure channel for SSL/TLS with authority 'la.www4.irs.gov'.
Stack Trace : Server stack trace:
at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
at System.ServiceModel.Channels.HttpChannelFactory1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout) at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.SecurityChannelFactory1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at MeFWCFClient.MeFMSIServices.Login.Login(LoginRequest request)
basically we do taxes, we take the xml, zip it up and send it to the IRS through their web services, they provide an SDK that we use to build a DLL that we use in our app to communicate with them, through the DLL we send/receive the returns and such.
Yes, and as I understand it Windows "Lazy Loading" takes care of keeping the CA store updated with needed root certs (like ISRG Root X1).
That looks like a comms timeout problem to me. Not any kind of cert validation failure.
Were there any other kind of changes to your network config lately?
5 Likes
no network changes lately, we are also on a cloud server. our server has pretty much been the same for the past few years, only code changes to homebuilt apps on it.
Did you trim off some of the error message? Because google shows similar errors for comms timeout problems that look like this
Exception information:
Exception type: TimeoutException
Exception message: The HTTP request to '(URL of destination)' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout.
at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
Has anyone changed any firewall settings lately that would affect outbound requests?
I don't see this as cert related. A timeout is your app unable to reach the destination. If it was a cert problem you can reach the destination but your system does not "like" the cert it saw. In this case you never got to the destination (looks like anyway).
Are you able to insert any debug code to evaluate your calls and settings in detail? Like exactly what your timeout value is?
5 Likes
No firewall changes that i know of unless it was by the cloud hosting company that we don't know about (unlikely), Timeout on the app is set at the config level.
Config setting for login to web services
<!-- Timeout values for login is set at 10 minutes. Please change if needed -->
<binding name="LoginCustomBinding" openTimeout="00:10:00" closeTimeout="00:10:00" sendTimeout="00:10:00" receiveTimeout="00:10:00">
<security allowSerializedSigningTokenOnReply="false" authenticationMode="MutualCertificate" securityHeaderLayout="Strict" includeTimestamp="true"
messageProtectionOrder="SignBeforeEncrypt" messageSecurityVersion="WSSecurity10WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10"
requireSignatureConfirmation="false" enableUnsecuredResponse="true" defaultAlgorithmSuite="Basic128Sha256Rsa15">
<localClientSettings detectReplays="false" reconnectTransportOnFailure="true" />
<secureConversationBootstrap />
</security>
<LoginTextMessageEncoding />
<httpsTransport keepAliveEnabled="true" requireClientCertificate="false" />
</binding>
10min timeout is very long so should not need increasing. We're not a general purpose comms help site. I was just giving ideas on things to focus your efforts. I don't see any evidence this is cert related.
Lots of things can "get in the way" of making a connection.
Have you tried posting this timeout problem on a Windows Server forum?
4 Likes
That needs some more detail/explaining.
And I agree:
That said, you haven't provided the actual FQDN and port your DLL is using.
2 Likes
When your software is trying to connect to a service over https the operating system negotiates a common set of TLS Cipher Suites.
If one side doesn't support a set that the other side supports then they cannot communicate.
On windows the easiest way to review and configure TLS protocol levels and cipher suites is using the free tool Nartac Software - IIS Crypto - I usually set the "Best Practices" mode.
On Windows Server 2012 in particular many ECDSA cipher suites are not enabled by default, so if the service is using an EC key (instead of RSA) this impacts the set of cipher suites they can use to communicate.
Another thing to be ware of is that in older version of .net TLS1.2 is not available by default and instead you need to enable it, a bit like this article: Configure TLS 1.2 on Windows clients accessing Azure Stack Edge Pro GPU device | Microsoft Learn and in C# that can be achieved with: System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
3 Likes
At least this might not be the issue if that is the correct domain name and using port 443.
And plenty of good suggestions. But, would the wrong cipher suites or TLS level support cause a timeout? Or am I over-interpreting that error message?
3 Likes
Looking at it more, I think the timeout thing is a red herring and that it's probably a different failure.
The client application calls the IRS (soap based) service using an old-ish .net technology called WCF (which dates back to when SOAP seemed like a good idea), but establishes the connection using a client certificate via MTLS, so I think either the TLS conversation is failing on cipher suite or it's failing on client certificate. If client certificate then the IRS probably need to be notified of the current certificate the client is using.
It's possible that the app loads a client certificate to use for the conversation. This will be in the machine store or on disk. It's important that the IRS accept this certificate as the current client certificate for this application.
Maybe they do actually expect people to import their server cert as some sort of trust mechanism but that seems a bit off, especially for a 90 day cert. I had a quick look at their docs but I can't really make sense of government IT speak.
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.