Skip to content

5.1 - SANs for internal names are no longer needed. #4991

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
0rnela merged 1 commit into from
Jun 9, 2026
Merged

5.1 - SANs for internal names are no longer needed. #4991

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion modules/administration/pages/ssl-certs-imported.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,8 @@ Supported Key types are [literal]``RSA`` and [literal]``EC`` (Elliptic Curve).

[IMPORTANT]
====
Database SSL certificates require [literal]``reportdb`` and [literal]``db`` as [literal]``Subject Alternative Name``.
In previous versions the database SSL certificates required [literal]``reportdb`` and [literal]``db`` as [literal]``Subject Alternative Name``.
This is no longer needed.
====

Third-party authorities commonly use intermediate CAs to sign requested server certificates.
Expand Down
23 changes: 1 addition & 22 deletions ...-upgrade/pages/container-deployment/mlm/migrations/server/server-mlm-50-51.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,28 +43,7 @@ ifdef::backend-pdf[]
include::../../../../../partials/snippet-ssl-migration-certs.adoc[leveloffset=+1]
endif::[]

[NOTE]
====
{productname} 5.0 peripheral servers are always using third-party SSL certificates.
If the hub server has generated the certificates for the peripheral server, it needs to generate the certificate for the peripheral database too.
On the hub server, run the following command for each of the peripheral server to migrate.

[source,shell]
----
mgrctl exec -ti -- rhn-ssl-tool --gen-server --dir="/root/ssl-build" --set-country="COUNTRY" \
--set-state="STATE" --set-city="CITY" --set-org="ORGANIZATION" \
--set-org-unit="ORGANIZATION UNIT" --set-email="name@example.com" \
--set-hostname=<hostname>-reportdb --set-cname="example.com" --set-cname=db --set-cname=reportdb
----

The files to use will be inside the server container and need to be copied to the new peripheral server host:

* [literal]``/root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT`` as the root CA,

* [literal]``/root/ssl-build/<hostname>-reportdb/server.crt`` as the db certificate and

* [literal]``/root/ssl-build/<hostname>-reportdb/server.key`` as the db certificate's key.
====
During a migration the server SSL certificate and CA chain are copied from the source server.



Expand Down
11 changes: 7 additions & 4 deletions ...allation-and-upgrade/pages/container-management/updating-server-containers.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,15 +134,18 @@ ____


.Upgrading with third-party SSL certificate
[IMPORTANT]
[NOTE]
====
If you are using third-party certificates, the database container needs to have an SSL certificate with the following Subject Alternate Names (SANs):
In previous versions, the database container needed to have an SSL certificate with the following Subject Alternate Names (SANs):

* [literal]``db``
* [literal]``reportdb``
* the externally facing fully qualified domain name

The same certificate can be used for both the main container and the database one, but it needs to have those SANs too.
This is no longer required.
The database container needs only the externally facing fully qualified domain name.
The old certificates with [literal]``db`` and [literal]``reportdb`` SANs can be still used.

The same certificate can be used for both the main container and the database one.

In order to pass the new certificates to the upgrade command, use the [command]``--ssl-db-ca-root``, [command]``--ssl-db-cert`` and [command]``--ssl-db-key`` parameters.
====
Expand Down
14 changes: 1 addition & 13 deletions modules/specialized-guides/pages/large-deployments/hub-install.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,12 +26,6 @@ You can deploy a hub environment either with third party certificates or with se
// while deploying the hub infrastructure?
Prepare third party certificates for both the Hub Server and the Peripheral servers first.

[IMPORTANT]
====
Database SSL certificates require [literal]``reportdb`` and [literal]``db`` as [literal]``Subject Alternative Name``.
The same certificate can be used for server and database, as long the required alternative names are added.
====

// Hub:
// mgradm install podman --ssl-ca-root CA-Certificate.crt --ssl-server-cert hub.crt --ssl-server-key hub.key --hubxmlrpc-replicas 1

Expand Down Expand Up @@ -135,12 +129,6 @@ Next step, peripheral server
[[lsd-hub-install-self-peripheral]]
=== Peripheral servers

[IMPORTANT]
====
Database SSL certificates require [literal]``reportdb`` and [literal]``db`` as [literal]``Subject Alternative Name``.
The same certificate can be used for server and database, as long the required alternative names are added.
====

.Procedure: Peripheral servers with self-generated certificates
[role=procedure]
_____
Expand All @@ -164,7 +152,7 @@ mgrctl term
rhn-ssl-tool --gen-server --dir="/root/ssl-build" --set-country="COUNTRY" \
--set-state="STATE" --set-city="CITY" --set-org="ORGANIZATION" \
--set-org-unit="ORGANIZATION UNIT" --set-email="name@example.com" \
--set-hostname=PERIPHAL-FQDN --set-cname="reportdb" --set-cname="db"
--set-hostname=PERIPHAL-FQDN
----

. For every peripheral server:
Expand Down
Loading