Hi!
I've faced with a problem caused by the fix for following issue: #1596
The problem happens in the following use-case.
Configuration:
- map-type is x509c2n:san-rfc822-name. I suspect any value except "specified" will be an issue too.
- fingerprint of the trusted certificate is configured in the cert-to-name
- username is embedded into the client's certificate
- there is no username in the CA certificate
<certificate-parameters xmlns="urn:o-ran:certificates:1.0">
<cert-maps>
<cert-to-name>
<id>0</id>
<!-- fingerprint of CA certificate -->
<fingerprint>02:21:9F:FE:4F:0D:0B:EB:E4:7B:FF:88:8E:8E:7D:5B:2F:80:AE:26:B3</fingerprint>
<!-- username will be in the client certificate -->
<map-type xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name">x509c2n:san-rfc822-name</map-type>
</cert-to-name>
</cert-maps>
</certificate-parameters>
Current implementation seems to ignore username from the client certificate even though CA certificate does not contain any.
I've read carefully RFC 6353 and it does not say that username in the CA certificate has higher priority than username in the client certificate. I think that following logic would make sense:
- take username from the client certificate if present,
- if not, use username from the trust chain.
- if there are several usernames in the trust chain - take one which is closer to the client certificate.
This solution is compliant to the RFC 6353 and also allows more flexibility for the access management.
Here is my patch. It is not fully tested yet:
$ git diff
diff --git a/src/session_server_tls.c b/src/session_server_tls.c
index 03574c2..c228bfd 100644
--- a/src/session_server_tls.c
+++ b/src/session_server_tls.c
@@ -448,18 +448,25 @@ nc_server_tls_cert_to_name(struct nc_ctn *ctn, void *cert_chain, char **username
/* found a fingerprint match, try to obtain the username */
VRB(NULL, "Cert verify CTN: entry with a matching fingerprint found.");
DBG(NULL, "Cert verify CTN: matched fingerprint: %s (id %" PRIu32 ").", ctn->fingerprint, ctn->id);
- ret = nc_server_tls_get_username(cert, ctn, username);
- if (ret == -1) {
- /* fatal error */
- goto cleanup;
- } else if (!ret) {
- /* username found */
- goto cleanup;
- }
+ }
+
+ if (!(*username) && !nc_server_tls_get_username(cert, ctn, username)) {
+ VRB(NULL, "Cert verify CTN: found userneame %s.", *username);
+ }
+
+ if(fingerprint_match && *username)
+ {
+ ret = 0;
+ goto cleanup;
}
}
cleanup:
+ if(ret != 0 && *username)
+ {
+ free(*username);
+ *username = NULL;
+ }
return ret;
}
libnetconf version:
-Sergii
Hi!
I've faced with a problem caused by the fix for following issue: #1596
The problem happens in the following use-case.
Configuration:
Current implementation seems to ignore username from the client certificate even though CA certificate does not contain any.
I've read carefully RFC 6353 and it does not say that username in the CA certificate has higher priority than username in the client certificate. I think that following logic would make sense:
This solution is compliant to the RFC 6353 and also allows more flexibility for the access management.
Here is my patch. It is not fully tested yet:
libnetconf version:
-Sergii