Log In
Register
Topic RSS
16:40, EEST
March 16, 2017
Offline
Hi,
when the server certificate is validate there is an EnumSet of the checks passed.
ValidationResult onValidate(Cert certificate,
ApplicationDescription applicationDescription,
EnumSet passedChecks)
When I take a look at enum CertificateCheck, it has the values ‘SelfSigned, Signature, Trusted, Uri, UriValid, Validity)
I wonder if there is also a check for the hostname? Is there also a possibility to validate the hostname from the subjectAlternativeNames of the certificate against the endpoint url?
11:16, EEST
April 3, 2012
Offline
Hi,
There is no built-in check for the hostname, but we do have a sample of how such check can be made within com.prosysopc.ua.samples.client.MyCertificateValidationListener in the sampleconsoleclient: https://documentation.prosysop…..l#line.147, please also read the comments https://documentation.prosysop…..ml#line.75, copied below:
“
/*
* Validate that the cert is made for the host we are trying to connect. This is similar to what
* web browsers do for https connections.
*
* However, the PKI public key infrastructure only in practice works in the public network. OPC
* UA also mostly doesn’t run in public network, but instead on factory floors etc. and
* connections are often made behind servers that are behind NAT (network address translation)
* layers.
*
* OPC UA spec says that the endpointUrl of the EndpointDescription should be checked, but also
* allows clients to use the original address (the NAT case). Thus, this validation must be done
* using the original connection address.
*
* However, if the server doesn’t know about the NAT and the it’s certificate was not made with
* this knowledge, then this check basically always fails. In an ideal world, the server should
* always know it is behind a NAT and the cert be made include the “NAT address”, but this may
* prove to be close to impossible in practice in some cases. The specification allows this
* check to be suppressed. Thus, you should build in your application a way to do this. The
* following method asks the user if there is a mismatch with the option to allow connecting.
*
* Note that the DefaultCertificateValidator works in both client and server side and this is a
* client-side check only, thus for the time being this must be handled in the application layer
* (as the DefaultCertificateValidator is not aware of the connection address). Some future SDK
* version might offer alternative solutions.
*
* Also, this happens if e.g. ‘localhost’ was used as a connection address, but the server only
* offers EndpointDescriptions with the hostname part.
*/
boolean accept = validateHostnameOfCertificate(certificate);
“
13:05, EEST
March 16, 2017
Offline
Thank you for the example
17:07, EEST
March 16, 2017
Offline
One additional question about this topic.
What about case sensitivity?
I’ve check to code from the sample console client and basically it does this:
String host = client.getAddress().getHost();
List certificateDnsNames = CertificateUtils.getDnsOfCertificate(certificate);
List certificateIpAddresses = CertificateUtils.getIpOfCertificate(certificate);
if (certificateDnsNames.contains(host) || certificateIpAddresses.contains(host))
{
return true;
}
When I have a URL like ‘opc.tcp://myhost:53530/OPCUA/SimulationServer’ but the server certificate has a DNS entry MYHOST, the check will fail as MYHOST does not contain myhost.
Can you tell in which form the CertificateUtils.getDnsOfCertificate(certificate) is returning the DNS names? Is it always upper case, or is it exactly the string contained in the certificates subject alternative names?
Thanks!
18:12, EEST
December 21, 2011
Offline
It returns them currently as they are in the certificate, which of course is not very nice. It would be good to fix it to return them always in lowercase, to ensure that you can do the check more reliably.
