EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  <20242025  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  <20242025 
<== Date ==> <== Thread ==>

Subject: RE: OPCUA SSL problem
From: Majer Karel via Tech-talk <tech-talk at aps.anl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Thu, 10 Oct 2024 20:05:34 +0000
Hello Dirk,

Thanks for your reply. As I have written in other posts in the meantime, the URI is set up correctly and this warning appears every time even in working IOCs using open62541 client for security policy None. If the URI is not set up correctly (we had that issue before), the warning appears for every security policy and the IOC doesn't work.

We have used Wireshark to determine that the problem is not server trust. The client closes TCP connection after receiving OpenSecureChannelResponse from the server, before the client certificate is even sent. Although the warning suggests trust issue on the client side, the server certificate is OK, because we can connect with UAExpert and we finally got the IOC built with UA SDK running as well. OpenSSL is used in all cases. I think the issue is some incompatibility between open62541 client and the ProSoft server which we connect to. I had a look at open62541 source code and I think that error in parsing the server response would manifest as BadCertificateUntrusted, but I'm not skilled enough with C++ to know for sure.

Best regards,

Karel

-----Original Message-----
From: Zimoch Dirk <dirk.zimoch at psi.ch> 
Sent: Thursday, October 10, 2024 6:06 PM
To: Majer Karel <Karel.Majer at eli-beams.eu>; tech-talk at aps.anl.gov
Subject: Re: OPCUA SSL problem

Your OPCUA client warns: The configured ApplicationURI does not match the URI specified in the certificate for the SecurityPolicy Your OPCUA server may not like that and refuse connection with BadCertificateUntrusted.

You can see your ApplicationURI with: opcuaShowSecurity You can see the URI in your certificate with:
openssl x509 -noout -text -in /usr/openssl/cert.der | grep grep URI

IOC name and host name must match.


On Wed, 2024-10-02 at 13:16 +0000, Majer Karel via Tech-talk wrote:
> Hello,
>  
> I am using EPICS OPCUA module built with Open62541 v1.3.10 and OpenSSL, running on Rocky Linux 9. It is mostly used to connect to B&R PLCs which have self-signed server certificate and then it runs without problems.
> I need to communicate also with another server which has certificate signed by a certification authority. The authority uses a self-signed certificate. I cannot get this communication working in any setup.
> This is the output of EPICS shell:
>  
> [root@fct-deploy20 iocopcua]# ./st.cmd #!../../bin/linux-x86_64/opcua 
> < envPaths
> epicsEnvSet("IOC","iocopcua")
> epicsEnvSet("TOP","/usr/EPICS/IOCs/opcua")
> epicsEnvSet("EPICS_BASE","/usr/EPICS/epics-base")
> epicsEnvSet("OPCUA","/usr/EPICS/support/opcua")
> cd "/usr/EPICS/IOCs/opcua"
> ## Register all support components
> dbLoadDatabase "dbd/opcua.dbd"
> opcua_registerRecordDeviceDriver pdbbase opcuaSession PLC 
> opc.tcp://192.168.0.250:4840 opcuaOptions PLC debug=1 Session PLC: 
> setting option debug to 1 opcuaSetupPKI /usr/PKI OPC UA: Warning - a 
> PKI directory is writable, which may compromise security. 
> (/usr/PKI/trusted/certs) OPC UA: Warning - a PKI directory is 
> writable, which may compromise security. (/usr/PKI/trusted/crl) OPC 
> UA: Warning - a PKI directory is writable, which may compromise 
> security. (/usr/PKI/issuers/certs) OPC UA: Warning - a PKI directory 
> is writable, which may compromise security. (/usr/PKI/issuers/crl) 
> opcuaClientCertificate /usr/openssl/cert.der /usr/openssl/key.pem 
> opcuaOptions PLC sec-policy=Basic256Sha256 Session PLC: setting option 
> sec-policy to Basic256Sha256 opcuaSubscription RockwellPSI PLC 100
> dbLoadRecords("db/FCT-RockwellPSI.db")
> cd "/usr/EPICS/IOCs/opcua/iocBoot/iocopcua"
> iocInit
> Starting iocInit
> ######################################################################
> ######
> ## EPICS R7.0.8
> ## Rev. 2024-05-07T19:43+0000
> ## Rev. Date build date/time:
> ######################################################################
> ###### OPC UA Client Device Support 0.10.0-dev (-); using Open62541 
> Client API v1.3.10
> iocRun: All initialization complete
> OPC UA: Autoconnecting sessions
> Session PLC already disconnected
> Session PLC: (initClientSecurity) loading client certificate 
> /usr/openssl/cert.der Session PLC: (initClientSecurity) loading client private key /usr/openssl/key.pem
> [2024-10-02 12:46:41.325 (UTC+0000)] warn/userland      AcceptAll Certificate Verification. Any remote certificate will be accepted.
> [2024-10-02 12:46:41.326 (UTC+0000)] info/securitypolicy        The Basic128Rsa15 security policy with openssl is added.
> [2024-10-02 12:46:41.328 (UTC+0000)] info/securitypolicy        The basic256 security policy with openssl is added.
> [2024-10-02 12:46:41.329 (UTC+0000)] info/securitypolicy        The basic256sha256 security policy with openssl is added.
> [2024-10-02 12:46:41.330 (UTC+0000)] info/securitypolicy        The Aes128Sha256RsaOaep security policy with openssl is added.
> Session PLC: (connect) setting up PKI provider Session PLC: 
> (setupIdentity) setting Anonymous token Session PLC: (setupSecurity) 
> reading endpoints from opc.tcp://192.168.0.250:4840
> [2024-10-02 12:46:41.331 (UTC+0000)] warn/client        The configured ApplicationURI does not match the URI specified in the certificate for the SecurityPolicy https://urldefense.us/v3/__http://opcfoundation.org/UA/SecurityPolicy*None__;Iw!!G_uCfscf7eWS!fCZnrySsvi7YYgcw1Bmk0M1UCNrZ2PUUvYPCHpK8jMURBNDaoylL4_5PUb5jXbUCGPMI6qehuTFljJdm-B9Zt3rUJAMn5Q$ 
> [2024-10-02 12:46:41.335 (UTC+0000)] info/server        Reloading the trust-list
> [2024-10-02 12:46:41.336 (UTC+0000)] info/server        Reloading the issuer-list
> [2024-10-02 12:46:41.336 (UTC+0000)] info/server        Reloading the revocation-list
> [2024-10-02 12:46:41.336 (UTC+0000)] warn/channel       Connection 8 | SecureChannel 0 | Receiving the response failed with StatusCode BadCertificateUntrusted
> [2024-10-02 12:46:41.336 (UTC+0000)] info/client        Client Status: ChannelState: Closed, SessionState: Closed, ConnectStatus: BadConnectionClosed
> Session PLC: (setupSecurity) UaDiscovery::getEndpoints from 
> opc.tcp://192.168.0.250:4840 failed with status BadConnectionClosed 
> OPC UA session PLC: security discovery and setup failed with status 
> cantConnect
>  
> We used tcpdump to capture TCP communication, it shows TCP is closed by client after receiving OpenSecureChannelResponse from the server.
> We have certificate of both the authority and the server and crl of the authority. This is a list of steps which we tried and still got BadCertificateUntrusted:
> ·         Putting server certificate into PKI/trusted/certs
> ·         Putting CA certificate into PKI/trusted/certs and crl into PKI/trusted/crl
> ·         Putting CA certificate into PKI/issuers/certs and crl into PKI/issuers/crl
> ·         Combinations of all of the above
> ·         Adding certificates to the system
> ·         Running with sec-mode=None and commenting out opcuaSetupPKI command
> We also tried running the IOC with strace to see system calls and noticed that PKI/trusted/crl directory was not opened during IOC startup.
> We have used openssl verify to check the server certificate against the CA with OK result.
>  
> And perhaps most importantly, we can connect to the server with UAExpert without any issues when we use the same certificates.
>  
> Do you have any experience with this behavior and any advice how to fix it or even where to look for the problem?
>  
> Kind regards,
>  
> Karel Majer
>  
>  
> Karel Majer | Senior Software Developer
> Tel: +420 266 051 514
> Email: karel.majer at eli-beams.eu
>  	 ELI Beamlines Facility|The Extreme Light Infrastructure ERIC Za 
> Radnicí 835, 252 41 Dolní Břežany, Czech Republic
> https://urldefense.us/v3/__http://www.eli-laser.eu__;!!G_uCfscf7eWS!fCZnrySsvi7YYgcw1Bmk0M1UCNrZ2PUUvYPCHpK8jMURBNDaoylL4_5PUb5jXbUCGPMI6qehuTFljJdm-B9Zt3rk_zZNVQ$ |https://urldefense.us/v3/__http://www.eli-beams.eu__;!!G_uCfscf7eWS!fCZnrySsvi7YYgcw1Bmk0M1UCNrZ2PUUvYPCHpK8jMURBNDaoylL4_5PUb5jXbUCGPMI6qehuTFljJdm-B9Zt3rGat2W7w$      
>  
>  

Replies:
Re: OPCUA SSL problem Michael Davidsaver via Tech-talk
References:
OPCUA SSL problem Majer Karel via Tech-talk
Re: OPCUA SSL problem Zimoch Dirk via Tech-talk

Navigate by Date:
Prev: RE: OPCUA SSL problem Majer Karel via Tech-talk
Next: Re: OPCUA SSL problem Michael Davidsaver via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  <20242025 
Navigate by Thread:
Prev: Re: OPCUA SSL problem Zimoch Dirk via Tech-talk
Next: Re: OPCUA SSL problem Michael Davidsaver via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  <20242025 
ANJ, 10 Oct 2024 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions ·
· Download · Search · IRMIS · Talk · Documents · Links · Licensing ·