Project

General

Profile

Actions

Bug #652

closed

Multi-value extensions are not always correctly created

Added by Felix Tiede over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
02/02/2020
Due date:
02/28/2020
% Done:

100%

Estimated time:
10:00 h
Spent time:

Description

Subject Alternative Names (subjectAltName) is always a multi-value extension, but not created as such, if only one entry for the extension exists.

The low-level problem with this is to "know" if an extension is multi-value beforehand and correctly creating it as such even with only one value.

A hacky solution is to add the request's subject common name as a DNS-based entry, technically enforcing subjectAltName to be created as multi-value, but that does not work for every extension, so a better solution needs to be found here.

Actions #1

Updated by Felix Tiede over 5 years ago

  • % Done changed from 0 to 70
Actions #2

Updated by Felix Tiede over 5 years ago

The current solution is now more flexible and uses the extension's nid to determine necessary behavior.

This still poses the issue that it is not generally known whether or not an extension requires encoding as collection or not, so it's possible, an API addendum to X509Extension is required to expose this new feature properly. This is, however, not exactly in the scope of this bug.

Actions #3

Updated by Felix Tiede over 5 years ago

  • % Done changed from 70 to 80

With f814b0b69a589952abc6ed1219816e5976529bb5 class X509Extension has learned to adhere to what was loaded from OpenSSL backend.

Actions #4

Updated by Felix Tiede over 5 years ago

  • Target version set to 6.0.1
Actions #5

Updated by Felix Tiede over 5 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 80 to 100
Actions

Also available in: Atom PDF