View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004170 | 10000-004: Services | Spec | public | 2018-02-23 12:11 | 2020-09-16 14:01 |
| Reporter | Martin Regen | Assigned To | Matthias Damm | ||
| Priority | normal | Severity | text | Reproducibility | sometimes |
| Status | closed | Resolution | no change required | ||
| Platform | UA .Net Standard | OS | Windows/Linux/OSX | OS Version | Any |
| Summary | 0004170: Clarification is needed on user certificate fields (security) | ||||
| Description | Issue found during IOP Workshop 2018 Issue: Emerson client couldn't connect to UA .Net Standard reference server using user cert authentication with self signed cert. Issue: .NetStandard Ref server doesn’t accept user certificate because it contains an application URI. Application certs are not accepted as user certs, because signed app certs could grant access as authenticated user. CTT tests require to check URL. Test Security/Security User X509/007 fails if app cert can be used as user cert. It becomes specifically a problem when a CA issues application and user certs, that's why certs with application URI should be refused for user auth. | ||||
| Steps To Reproduce | -start .Net Standard ref server (from GitHub repo) mail thread: From: Randy Armstrong (OPC) [mailto:randy.armstrong@opcfoundation.org] Hi All, When these kinds of issues come up there needs to be a mantis issue raised against the appropriate specification part: This will ensure the WG will eventually address it. You can do this editing the meeting for the day you would like to attend and add your name (important) + Mantis #. As for the issue: user certificates has been deliberately left open ended because we don’t want to prevent end users from using whatever end user certificates they are already providing (i.e. smart cards provided to operators). Servers need to check for valid x509 with a path to a trusted root. Any additional requirements are vendor specific. We can discuss whether this is too open ended in a UA WG call. Regards, Randy From: Paul Hunkar (OPC) [mailto:paul.hunkar@opcfoundation.org] Daniel, Martin, I thought one of you were going to enter the Mantis issue? Usually it looks better if it is entered by someone else than OPC. I did do some research – the spec has no guidance on X.509 certificate for user authentication – it should include some basic information . The specification only describes how to process the x.509 certificate – not what is in the certificate or anything about the certificate. A quick internet search seems to indicate that there are some items that seem to commonly be required: keyUsage = digitalSignature It also seems that it is common to require a single CA for issuing user certificates. If standard software has additional requirements we should document this also. Paul From: Orozco, Daniel [AUTOSOL/PSS/AUS] Hi Martin, Have not heard back from OPC UA Foundation yet either. Best Regards, -Daniel From: Martin Regen [mailto:Martin.Regen@microsoft.com] Hi Daniel and Paul, I’m also interested in the outcome of the discussion. Is there yet a Mantis issue open to discuss this or has there been a conclusion? Just as reminder of our discussion in the IOP workshop, the user cert authentication of Daniels cert failed on the UA.NetStandard ref server because the cert had an application URI in it. Cheers, Mit freundlichen Grüßen, From: Orozco, Daniel [AUTOSOL/PSS/AUS] [mailto:Daniel.Orozco@Emerson.com] Hi Paul, Glad we were part of the OPC UA IOP at Phoenix AZ. Thanks for organizing it! The intention of this e-mail is just a reminder that the OPC UA specifications need some attention regarding User Certificate properties and usage. Some initial questions about the user (token) certificate are:
Thanks, -Daniel | ||||
| Additional Information | opcuser is a valid user cert used by the CTT (see URI=compliance@opcfoundation.org) | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Commit Version | |||||
| Fix Due Date | |||||
|
|
The URI field in the subjectAltName is a generic field that holds any URI that identifies the subject. We use this field for UA as the ApplicationURI, however, others may use this field to mean something else. This means we can't know a certificate is an "application certificate" simply by checking for the presence of the URI field. What we could do is prohibit the use of the same URI specified in the client application certificate. That should ensure the user cert was intended to be a user cert. The CTT tests need to be changed. |
|
|
Agreed, imho all boils down to properly craft the PKI to prevent the use of application certs as user certs. The reference stack needs a separate user/https trust list to fix the issue. Checking the URI field is not the right approach. Just check for the same URI instead. CTT wise: CTT test 1.03 signs both user and app issued certs with the same CA. This exhibits the problem above. CTT should use a 'User CA' and a 'App CA' to create issuer certs for both and try connection with 'issued user cert' and 'issued app cert' to catch a case where the server does not have a dedicated user trust list that allows a properly crafted PKI. |
|
|
needs clarification in Part 4. |
|
|
This was mainly a bug in the sample code |
|
|
Agreed to no-change-required in Virtual F2F. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-02-23 12:11 | Martin Regen | New Issue | |
| 2018-02-23 12:11 | Martin Regen | File Added: Valid and invalid user cert.zip | |
| 2018-02-23 12:25 | Randy Armstrong | Note Added: 0008890 | |
| 2018-03-07 10:57 | Martin Regen | Note Added: 0008907 | |
| 2018-04-24 16:37 | Jim Luth | Note Added: 0009014 | |
| 2018-04-24 16:37 | Jim Luth | Assigned To | => Matthias Damm |
| 2018-04-24 16:37 | Jim Luth | Status | new => assigned |
| 2020-09-16 14:01 | Matthias Damm | Status | assigned => resolved |
| 2020-09-16 14:01 | Matthias Damm | Resolution | open => no change required |
| 2020-09-16 14:01 | Matthias Damm | Note Added: 0012851 | |
| 2020-09-16 14:01 | Jim Luth | Status | resolved => closed |
| 2020-09-16 14:01 | Jim Luth | Note Added: 0012852 |
