Open KircMax opened 3 days ago
When reducing to ApplicationConfiguration.CertificateValidator.GetIssuers(client.Certificate, issuers).ConfigureAwait(continueOnCapturedContext: false); it will throw an exception inside but not fail, but afterwards the issuers count will still be 0 and it will later be treated like self-signed (which it isn't)
Certificates: T900_CaSignedClientCertificate.zip
it seems we end up in here - also when AutoAcceptUntrustedCertificates is true ... To me it seems like there is no getIssuer that will get the issuer X509Certificate2 certificate by the extension of the X509Certificate2 "issuedcertificate"
this one worked fine: public static X509Certificate2 GetIssuer(X509Certificate2 leafCert) { if (leafCert.Subject == leafCert.Issuer) { return leafCert; } X509Chain chain = new X509Chain(); chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck; chain.Build(leafCert); X509Certificate2 issuer = null; if (chain.ChainElements.Count > 1) { issuer = chain.ChainElements[1].Certificate; } return issuer; }
@KircMax not shure about your fix.
To me it seems you just didn`t configure an issuer store. If you create your security configuration at runtime did you use the ApplicationConfigurationBuilder? This will set suitable defaults.
To me AutoAcceptUntrustedCertificates should just allow the connection with untrusted servers in case of a client.
--> IMHO startup will work without any code changes if you put your issuer cert in the Issuer Store.
@romanett I agree that it'll work if I put my issuer certificates in the issuer store. I am not using the ApplicationConfigurationBuilder. It just was not necessary until now so I kind of expected that it would "keep working" without doing so. I am not sure why I need to trust the CAs that have signed the application certificate that I am using - if that is necessary then that is fine.
@KircMax thanks for the Update. To my knowledge this is expected behaviour. As the cert is only put in the issuer store you not really trust it, you just allow it to sign your certs.
It wasn't necessary before to have it in the issuers but yes - if that's expected behaviour we can close this Issue and abandon the PR.
but then I'd also expect another error message to be honest - the NullReferenceException does not really tell me that I'm missing the issuer certificates of my ApplicationCertificate in the Issuer Store.
@KircMax i think the nullreference exception occured because you didnt configure the issuer Store path
@romanett I can live with that being system behaviour ... I just wonder - do you have any RFC / Opc Spec. that made you implement a check for the ApplicationInstance owns certificate ? This used to work in the past so there prob. was a reason for that new check ? Thanks in advance.
Type of issue
Current Behavior
Currently I am not able to use a custom-assigned ca-signed Client Certificate.
Expected Behavior
using a ca-signed Client certificate works fine.
Steps To Reproduce
No response
Environment
Anything else?
using an ApplicationInstanceConfiguration with a custom assigned certificate then using the DefaultSessionFactory for the Session Creation -> which uses the Sessions LoadCertificateChain -> which uses the GetIssuers -> which uses the GetIssuerNoExceptionAsync -> NullReferenceException My certificateStore configuration at the time: