Support to get SubjectAltNames easily

[timlegge]

Description

Please include a summary of the proposed improvement or addressed issue.

Support to get SubjectAltNames easily. Initial version to gauge interest and for additional testing. Drop any valid certificate in the certs/ directory to test it against any other certificates:

perl -I blib/lib -I blib/arch t/san.t

Fixes/addresses (If applicable) # (issue) Possibly: Fixes #50 Fixes #40

Type of change

• [X] New feature (non-breaking change which adds functionality)
• [X] This change requires a documentation update

Checklist:

• [X] My code follows the style guidelines of this project
• [X] I have performed a self-review of my own code
• [X] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [X] My changes generate no new warnings
• [X] I have added tests that prove my fix is effective or that my feature works
• [X] New and existing unit tests pass locally with my changes
• [X] Any dependent changes have been merged and published in downstream modules
• [X] Changes have been manually tested (please provide information on test platform using the fields below)

Test / Development Platform Information

• Operating system and version Linux 5.13.0-22-generic Ubuntu SMP Fri Nov 5 13:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

• Crypt::OpenSSL::X509 version: master

• Perl version v5.32.1

• OpenSSL version OpenSSL 1.1.1l 24 Aug 2021

Please see the issue template for a more information on provided the requested information.

Please see the issue template for a more information on provided the requested information.

[wolfsage]

I see that this was merged but it is not documented - is that a mistake or is this not yet considered stable/supported API? Thanks

[timlegge]

That is likely on me. I think I meant to document and forgot. Will take a look.

Tim

Timothy Legge @. @.

On Mon, May 9, 2022 at 1:30 PM Matthew Horsfall (alh) < @.***> wrote:

I see that this was merged but it is not documented - is that a mistake or is this not yet considered stable/supported API? Thanks

— Reply to this email directly, view it on GitHub https://github.com/dsully/perl-crypt-openssl-x509/pull/92#issuecomment-1121321080, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH3N6336HFFQK2EALPQJO3VJE4SHANCNFSM5JLWFVMQ . You are receiving this because you authored the thread.Message ID: @.***>

[jonasbn]

Thanks @timlegge

[timlegge]

I suspect this should meet the needs. Not sure if it really needs the array/hash information.

diff --git a/X509.pm b/X509.pm
index 0436031..7bf39f9 100644
--- a/X509.pm
+++ b/X509.pm
@@ -410,6 +410,20 @@ Return a hash of Extensions indexed by OID or name.

 Return true if the certificate has the extension specified by C<OID>.

+=item subjectaltname ( )
+
+Uses Convert::ASN1 to extract the Subject Alternative Names from the X509 object.
+subjectaltname ( ) returns an array of "rfc822Name"s
+
+    [
+        {
+            'rfc822Name' => 'altuser@mpi-sws.org'
+        },
+        {
+            'rfc822Name' => 'user@mpi-sws.org'
+        },
+    ]
+

[jonasbn]

Hi @timlegge I have added your proposed documentation, it will be included in the next release.

@wolfsage sorry about any confusion, we missed the necessary update to the documentation. It is in the master branch now and will be included in the next release.

[timlegge]

thanks I meant to send a PR but did not get to it.

Timothy Legge @. @.

On Thu, May 12, 2022 at 5:07 PM Jonas Brømsø @.***> wrote:

Hi @timlegge https://github.com/timlegge I have added your proposed documentation, it will be included in the next release.

@wolfsage https://github.com/wolfsage sorry about any confusion, we missed the necessary update to the documentation. It is in the master branch now and will be included in the next release.

— Reply to this email directly, view it on GitHub https://github.com/dsully/perl-crypt-openssl-x509/pull/92#issuecomment-1125378390, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH3N6YACPR2FQEKI5HUT4LVJVQJJANCNFSM5JLWFVMQ . You are receiving this because you were mentioned.Message ID: @.***>

[wolfsage]

@wolfsage sorry about any confusion, we missed the necessary update to the documentation. It is in the master branch now and will be included in the next release.

Hey no worries! Thank you both!

[jonasbn]

@timlegge don't sweat it, it was an easy operation. And I needed something easy at this point :-)

[tlhackque]

Actually, the feature is great, but the documentation is a bit misleading.

rfc822Name is only one of the possible items returned. rfc822Name is strongly preferred to the legacy (deprecated) emailAddress component of a Subject's DN, so perhaps this is why it is emphasized.

Much more common are dNSName entries - which are hostnames.

Any certificate for more than one domain name has these. Typical is one duplicating the Subject's common name, and one for www.. Certificates for multiple hosts have more...

Experimentally, this works. So presumably other items (such as iPAddress, `uniformResourceIdentifier'...) would also decode. RFC 5280 has the full definition. I've also seen serial numbers (as for a hardware device) fairly frequently, but any OID is possible.

For example, this is typical of most certificates:

 x @{$x->subjectaltname}
0  HASH(0xa326098)
   'dNSName' => 'foo.example.net'
1  HASH(0xa320ea0)
   'dNSName' => 'www.foo.example.net'

I don't think a code change is required, just have the doc mention that the other item codes can be returned.

Edit: Fixed wrong quotation mark.