Redhat capsule servers Apache config file update

There are some vulnerability issues reported by a third party software. The issues are mostly related to Apache http server Configuration files.what is the best approach to update the capsule (production) servers. Should I use any script or Red hat satellite to update with some ansilble roles or any standard method. So that no downtime .Pls suggest.


Welcome to our forums.

In my experience third party software mostly scans and identifies issues of a generic Apache web server, which does not apply to Capsule, even though the component itself could be used as a generic web server. Maybe you could share with us the results of the scan, so we can know more of the issues reported. If any sensitive data is present in the report, please remove it before sharing (like IP addresses, hostnames, etc.).

1 Like

Thank you for your reply.
Due to security concerns I am sharing issues very briefly and my approach. Could you please have a look and comment. Since For new users are not allowed post links while I am trying to post hence screenshot attached

File structure:
β”œβ”€β”€ conf
β”‚ β”œβ”€β”€ httpd.conf β†’ (Base Configuration/Server Level)
β”‚ └── ports.conf - >(Port listening 443,80, 8443)
β”œβ”€β”€ conf.d β†’ (Vitural Host Level Files)
β”‚ β”œβ”€β”€ x.conf β†’ <VirtualHost *:443>
β”‚ β”œβ”€β”€ x2.conf β†’ <VirtualHost *:80>
β”‚ β”œβ”€β”€ y.reverse-proxy.conf β†’ <VirtualHost *:8443>
β”‚ └── ssl.conf β†’ (SSL Setting )Cipher etc
β”œβ”€β”€ conf.modules.d β†’ Apache Module
β”‚ β”œβ”€β”€ access_compat.load
β”‚ β”œβ”€β”€ …


Hi Sandman

Could you please comment


Well, quite some findings there.

I think hardening a Capsule by hand would only be temporary, since an update should overwrite modifications, or error out when finding non-factory settings.

About chipers, I think you can safely harden that part, provided that the clients can still communicate with the Capsule (which you can test with a client that runs the oldest versions of agents), but those old encryption modes are mostly in the configuration for extremely old client compatibility.

ServerName: clearly not used by clients.

RewrireEngine: since the rule is about redirecting http to https, and the clients should already use https only (that’s why Satellite generates certificates for them), you should be okay with the rule everywhere present.

CustomLog: your approach seems okay.

PidFile directory ownership: if httpd starts up with this setting and the service itself does not report any error, you are okay.

ServerSignature: you can safely turn it off.

Autoindex: unless you browse the published contents for some reason with a web browser, I think you can turn it off.

X-frames-options: clearly not used by the clients. May be of use if users access the Capsule directly from a browser.

Strict-Transport-Security: same as above

SSLUseStapling: I’m not sure the OCSP will give the Capsule the information needed for this to work, nor that clients would use it. But you can check this by monitoring network traffic between the OCSP and the Capsule, and also the OCSP and the clients. If clients don’t turn to the OCSP that often, you won a bit of traffic overhead.

While this is something that is always mentioned everywhere, I suggest that you backup your configuration before changing anything, and also test each and every option change before apply it to a production environment. If your clients run different versions of agents, test with each.

Also keep in mind that you may have to re-apply these changes after upgrades.