Using SSL certificate with empty CN field

[Sergey Kraynev]

I try to create the listener with HTTPs Terminated protocol and want to use SSL certificate with empty CN field.

I generate ssl in the following way:
```
openssl req -new -newkey rsa:4096 -nodes -keyout cert.key -out cert.csr
openssl x509 -req -sha256 -days 365 -in cert.csr -signkey cert.key -out cert.pem
```

And I get error like: Unreadable Certificate.

due to IndexError on the line:
https://github.com/openstack/octavia/blob/7310986de9bf68ed86de90de0501a1bc46945526/octavia/common/tls_utils/cert_parser.py#L262

It happens, because this code tries to get CN from certificate and gets empty list.

I did not find any note in haproxy docs, that SSL certificate without CN is not allowed.
The same in octavia validation or code. So it looks like octavia could process cn = None in the code.

Is it possible obtain CN optionally and if it's missed set to None?
If it's not allowed, let's handle it in the more user-friendly way with clear error message instead of traceback due with IndexError.

[Michael Johnson (johnsom)]

Here are a couple of initial comments:

1. Octavia is not just an implementation of HAProxy, so any restrictions or behaviors of HAProxy do not apply to the Octavia API necessarily.
2. We strive to be a standards based project, so the correct behavior should track back to standards documentation. In this case we are talking about the x.509 (ISO/IEC 9594-8:2020) ITU-T recommendation[1].

The subject field (CN is a subset option of subject) is described on page 16. I will excerpt the important two sentences here:

| If the public-key certificate is an end-entity public-key certificate (see clause 7.4), then the
| distinguished name may be an empty sequence providing that the subjectAltName extension is present and
| is flagged as critical (see clause 9.3.2.1). Otherwise, it shall be a non-empty distinguished name.

So the above openssl commands would in fact generate an invalid certificate assuming there is no openssl configuration file present that would meet the above requirements.

All of that said, I also think the get_host_names() code[2] is incorrect. It is valid for the subject field to be empty if the subject alternate name extension is present and mandatory.

So, there is a bug here, it's just a bit more complicated than the test case provided.

[1] https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.509-201910-I!!PDF-E&type=items
[2] https://github.com/openstack/octavia/blob/master/octavia/common/tls_utils/cert_parser.py#L247

[Michael Johnson (johnsom)]

I think a slightly better test command line would be:

openssl req -new -newkey rsa:4096 -nodes -keyout cert.key -out cert.crt -addext "subjectAltName = critical, DNS:www.example.com" -subj / -x509

[Sergey Kraynev (skraynev)]

Michael, thank you for response.

I did not want to say, that octavia code should strictly follow the haproxy standard.
Main point was about understanding octavia requirements, because:
- I initially thought, that this limitation is the same for haproxy
- I did not find any note in docs about octavia requirements for SSL.

So I agree with your statement, that it's not a bug and octavia expects another "correct" SSL certificate.

However , I suppose, that will be better to close bug with small changes in two ways:
- add note about SSL requirements, like you mentioned in comment above (thank you for detailed explanation, btw)
- add in code handling for case, when CN is empty and raise clear exception to avoid IndexError.

What do you think about it?

[Michael Johnson (johnsom)]

I think there is still a bug here in Octavia. I don't think it will handle my example code certificates either. It should accept an empty subject and process the subject alternate names as the standard states, but it is not.
I would leave this bug open to address that issue at least.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/octavia/+/901689

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/octavia/+/901689
Committed: https://opendev.org/openstack/octavia/commit/73cdee503ff1cb3419d8db0295b20b2b6ddf30c0
Submitter: "Zuul (22348)"
Branch: master

commit 73cdee503ff1cb3419d8db0295b20b2b6ddf30c0
Author: Michael Johnson <email address hidden>
Date: Wed Nov 22 21:45:44 2023 +0000

    Fix issue with certificates with no subject or CN

    This patch fixes an issue where if the user attempts to use a
    certificate that does not have a subject or CN, we would fail to create
    a listener using the certificate.
    Per the x.509 specification, a blank subject is allowed as long as the
    subjectAltName extension is present in the certificate.
    Octavia will now check for the a valid subAltName if the subject CN can
    not be retrieved. If both are missing an appropriate error is raised for
    the user.

    Closes-Bug: #2043582
    Change-Id: I06911f42b9bf29cf9a5f2e76d8333d8a2f1bc60b

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/yoga
Review: https://review.opendev.org/c/openstack/octavia/+/905097

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/zed
Review: https://review.opendev.org/c/openstack/octavia/+/905098

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/2023.1
Review: https://review.opendev.org/c/openstack/octavia/+/905099

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/2023.2
Review: https://review.opendev.org/c/openstack/octavia/+/905100

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/octavia/+/905098
Committed: https://opendev.org/openstack/octavia/commit/f72658259b3cb3d3a3b4e481086f48ff4a1930eb
Submitter: "Zuul (22348)"
Branch: stable/zed

commit f72658259b3cb3d3a3b4e481086f48ff4a1930eb
Author: Michael Johnson <email address hidden>
Date: Wed Nov 22 21:45:44 2023 +0000

    Fix issue with certificates with no subject or CN

    This patch fixes an issue where if the user attempts to use a
    certificate that does not have a subject or CN, we would fail to create
    a listener using the certificate.
    Per the x.509 specification, a blank subject is allowed as long as the
    subjectAltName extension is present in the certificate.
    Octavia will now check for the a valid subAltName if the subject CN can
    not be retrieved. If both are missing an appropriate error is raised for
    the user.

    Closes-Bug: #2043582
    Change-Id: I06911f42b9bf29cf9a5f2e76d8333d8a2f1bc60b
    (cherry picked from commit 73cdee503ff1cb3419d8db0295b20b2b6ddf30c0)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/octavia/+/905097
Committed: https://opendev.org/openstack/octavia/commit/0398dd6eddd9124257371a9028f98daf1406d112
Submitter: "Zuul (22348)"
Branch: stable/yoga

commit 0398dd6eddd9124257371a9028f98daf1406d112
Author: Michael Johnson <email address hidden>
Date: Wed Nov 22 21:45:44 2023 +0000

    Fix issue with certificates with no subject or CN

    This patch fixes an issue where if the user attempts to use a
    certificate that does not have a subject or CN, we would fail to create
    a listener using the certificate.
    Per the x.509 specification, a blank subject is allowed as long as the
    subjectAltName extension is present in the certificate.
    Octavia will now check for the a valid subAltName if the subject CN can
    not be retrieved. If both are missing an appropriate error is raised for
    the user.

    Closes-Bug: #2043582
    Change-Id: I06911f42b9bf29cf9a5f2e76d8333d8a2f1bc60b
    (cherry picked from commit 73cdee503ff1cb3419d8db0295b20b2b6ddf30c0)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/octavia/+/905100
Committed: https://opendev.org/openstack/octavia/commit/d0725c0846744347dfe850d7a7164b08cffd4ebb
Submitter: "Zuul (22348)"
Branch: stable/2023.2

commit d0725c0846744347dfe850d7a7164b08cffd4ebb
Author: Michael Johnson <email address hidden>
Date: Wed Nov 22 21:45:44 2023 +0000

    Fix issue with certificates with no subject or CN

    This patch fixes an issue where if the user attempts to use a
    certificate that does not have a subject or CN, we would fail to create
    a listener using the certificate.
    Per the x.509 specification, a blank subject is allowed as long as the
    subjectAltName extension is present in the certificate.
    Octavia will now check for the a valid subAltName if the subject CN can
    not be retrieved. If both are missing an appropriate error is raised for
    the user.

    Closes-Bug: #2043582
    Change-Id: I06911f42b9bf29cf9a5f2e76d8333d8a2f1bc60b
    (cherry picked from commit 73cdee503ff1cb3419d8db0295b20b2b6ddf30c0)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/octavia/+/905099
Committed: https://opendev.org/openstack/octavia/commit/20a7a26c165edef401eb3ebd775000b9d9ab71b5
Submitter: "Zuul (22348)"
Branch: stable/2023.1

commit 20a7a26c165edef401eb3ebd775000b9d9ab71b5
Author: Michael Johnson <email address hidden>
Date: Wed Nov 22 21:45:44 2023 +0000

    Fix issue with certificates with no subject or CN

    This patch fixes an issue where if the user attempts to use a
    certificate that does not have a subject or CN, we would fail to create
    a listener using the certificate.
    Per the x.509 specification, a blank subject is allowed as long as the
    subjectAltName extension is present in the certificate.
    Octavia will now check for the a valid subAltName if the subject CN can
    not be retrieved. If both are missing an appropriate error is raised for
    the user.

    Closes-Bug: #2043582
    Change-Id: I06911f42b9bf29cf9a5f2e76d8333d8a2f1bc60b
    (cherry picked from commit 73cdee503ff1cb3419d8db0295b20b2b6ddf30c0)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/octavia 10.1.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/octavia 11.0.2 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/octavia 14.0.0.0rc1 release candidate.