openssl_csr extendedKeyUsage should support custom oid

[rmja]

SUMMARY

The openssl_csr module should support custom OID's for extendedKeyUsage, example:

      openssl_csr:
        ...
        # 1.3.6.1.5.5.8.2.2 = iKEIntermediate, see http://oid-info.com/get/1.3.6.1.5.5.8.2.2
        extended_key_usage:
          - serverAuth
          - "1.3.6.1.5.5.8.2.2"
        ...

Applying this file currently returns:

  File "/tmp/ansible_openssl_csr_payload_5sf35e3e/ansible_openssl_csr_payload.zip/ansible/modules/crypto/openssl_csr.py", line 1088, in main
  File "/tmp/ansible_openssl_csr_payload_5sf35e3e/ansible_openssl_csr_payload.zip/ansible/modules/crypto/openssl_csr.py", line 541, in generate
  File "/tmp/ansible_openssl_csr_payload_5sf35e3e/ansible_openssl_csr_payload.zip/ansible/modules/crypto/openssl_csr.py", line 783, in _generate_csr
  File "/tmp/ansible_openssl_csr_payload_5sf35e3e/ansible_openssl_csr_payload.zip/ansible/modules/crypto/openssl_csr.py", line 783, in <listcomp>
  File "/tmp/ansible_openssl_csr_payload_5sf35e3e/ansible_openssl_csr_payload.zip/ansible/module_utils/crypto.py", line 1753, in cryptography_name_to_oid
    raise OpenSSLObjectError('Cannot find OID for "{0}"'.format(name))

ISSUE TYPE

• Feature Idea

COMPONENT NAME

openssl_csr

ADDITIONAL INFORMATION

The cryptography_name_to_oid should probably determine if the name passed in is already an oid, and return the input it if it was not found in the lookup table. There is also the inverse function which should simply return the oid if no name is found.

(this issue is migrated from ansible/ansible#69232)

[MarkusTeufelberger]

Maybe we could circumvent the lookup if a value is prefixed with OID: and hope that OpenSSL never gets the idea of prefixing one of their names that way?

Kinda like this:

  openssl_csr:
    ...
    # 1.3.6.1.5.5.8.2.2 = iKEIntermediate, see http://oid-info.com/get/1.3.6.1.5.5.8.2.2
    extended_key_usage:
      - serverAuth
      - "OID:1.3.6.1.5.5.8.2.2"
    ...

In this case however cryptography seems to insist on https://cryptography.io/en/latest/x509/reference/#cryptography.x509.oid.ExtendedKeyUsageOID for example - is this even really a valid OID in this context?

[rmja]

The prefix breaks parity with openssl where it is simply specified with the dotted notation. How about a simple regex test before the lookup?

[MarkusTeufelberger]

Do you have an example for such a simple regex in mind?

[rmja]

Just from the top of my head \d+(\.\d+)+ I do not know if it is fully compliant though... ons. 29. apr. 2020 21.56 skrev MarkusTeufelberger <[email protected]

…

: Do you have an example for such a simple regex in mind? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQDWMX4NEEQVXJLGJVT76TRPCA47ANCNFSM4MT2V45Q> .

[rmja]

Well of cause with start and end matching ^\d+(\.\d+)+$ ons. 29. apr. 2020 22.17 skrev Rasmus Melchior Jacobsen <[email protected]>:

…

Just from the top of my head \d+(\.\d+)+ I do not know if it is fully compliant though... ons. 29. apr. 2020 21.56 skrev MarkusTeufelberger < ***@***.***>: > Do you have an example for such a simple regex in mind? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#39 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAQDWMX4NEEQVXJLGJVT76TRPCA47ANCNFSM4MT2V45Q> > . >

[felixfontein]

This should be relatively simple to implement (probably updating cryptography_name_to_oid and maybe also cryptography_oid_to_name accordingly suffices). It doesn't make sense to work on it though before #27 hasn't been finished.

[felixfontein]

PR #91 implements this.