Autogen Fleet Cert Invalid Using IP Address

[jason-lacoss]

Version

2.4.40

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Distributed

Location

airgap

Hardware Specs

Exceeds minimum requirements

CPU

6

RAM

64

Storage for /

290GB

Storage for /nsm

720GB

Network Traffic Collection

span port

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Our SO stack sits behind its own firewall (required for our use case), so we NAT/port-forward agents to the manager using the client-side address. In the past, I have generated my own cert which included the agent-side firewall IP in the SAN. I added the firewall IP as an alternate FQDN in SOC, but the newly generated Fleet certificate shows it as "DNS" entry rather than an "IP Address" entry. That used to be ok, but is no longer permitted per RFC, so agents refuse to install saying the certificate is invalid for the given IP address. The only workaround has been to create a host entry on each client using the manager name with the firewall IP. That's not a very scalable solution. Is there a way to either: 1) Install a custom cert for elasticfleet-server using key/crt files similar to managerssl; or 2) Modify the CA/CSR template to mark the new FQDN as an "IP Address" rather than a "DNS" name?

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[jason-lacoss]

I have tried placing key/crt files at various places in the salt directory hoping they might get read when the container reboots, but so far no luck. e.g. /opt/so/saltstack/local/elasticfleet/files/certs/ssl.crt & ssl.key I also tried directly replacing the cert in /etc/pki, but the files get overwritten on container reload since that is a managed location.

[jason-lacoss]

I finally found the file driving the auto-generated fleet certificate. Look at /opt/so/saltstack/default/salt/ssl/init.sls on the manager. If you examine the section for so-fleet, you can see the FQDN entries being appended as SANs with the DNS tag. Change that from "DNS" to "IP", reboot, then modify the FQDN entry in SOC to force it to regenerate the cert. The SANs on my fleet certificate now show "IP Address" which should allow client agents to accept the certificate.

[jason-lacoss]

And confirmed -- Clients now see the certificate as valid for the additional firewall IP and install successfully. Might be nice to see an option in SOC so the admin/operator can specify what type of SAN should be created.

[defensivedepth]

@jason-lacoss We have typically focused on supporting DNS names vs. IP because of the inherent fragility of IPs. Is there a specific reason why it wouldn't work to configure a FQDN to point to that IP and then add that to the custom FQDN setting?

[jason-lacoss]

Hi Josh. I’m our case, SO is a mobile stack that gets deployed into various target networks based on tasking from higher authorities. We are not part of the target domain and have no way to publish dns to the target. The firewall IP is our only externally visible presence, so all of our hunt traffic appears to come from that address, and all agent traffic has to go to that address. If we were deploying in a fixed environment, then I would absolutely go with DNS. It’s just not an option for us under the limitations of how we have to operate.

[ColeVan]

Would you have time to chat more about the SAN DNS IP fix? I'm currently facing the same problem set.

[jason-lacoss]

I can try. What specifically are you looking for?

[ColeVan]

Actually, I think I may have figured it out. Pretty much the same exact situation as you where we can only have elastic agents communicate to external wan IP of our firewall and do not have the luxury of assigning pointer records in customer environments.

[jason-lacoss]

Ok. Let me know if you still have issues. I don’t have a dev instance in front of me, but I’ll help where I can. On Mar 22, 2024, at 7:18 PM, ColeVan ***@***.***> wrote: Actually, I think I may have figured it out. Pretty much the same exact situation as you where we can only have elastic agents communicate to external wan IP of our firewall and do not have the luxury of assigning pointer records in customer environments. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[ColeVan]

Here is my email if you would like to chat out of the this thread.

[email protected]