tryptyk Trusted Contributor.
Trusted Contributor.
484 views

Customer-supplied Certificate override in Syslog-ng TLS Setup

Jump to solution

Dear community,

I have this setup working perfectly currently:

A container in version 7.3 with Syslog-NG TLS with Customer-Supplied Certificate for Both Remote Management and Syslog NG.

For supporting the JSON extraprocessor feature, I needed to upgrade at least to 7.6.

The behavior was unexpected because the connector keeps generating a default certificate that "override" the current certificate. A "certificate mismatch" error appears in the management console because the certificate presented to both syslog-ng clients and remote management is the new default one.

I really would like to keep my actual PKI so I tried to remove the default certificate manually in the keystores (cacert, remote_management.p12, BCFIPS).. no way, at each restart of the container, the framework detects a "SubjectDN change" and creates a new certificate named with the alias localhost-x.x.x.x and appends it in remote_management.p12.

 

[2018-11-21 12:09:12,315][INFO ][default.com.arcsight.agent.e.a][init] SubjectDN change detected, creating a new keypair and certificate.
[2018-11-21 12:09:12,316][INFO ][default.com.arcsight.agent.e.a][createKeyPair] Creating Remote Management Keypair [/opt/arcsight/connectors/connector_1/current/jre/bin/keytool 
-genkey -alias CN=*.*.*.*,OU=WliMk8BABCAAVrVDOsLBg,O=ArcSight,L=NA,ST=NA,C=US -keyalg RSA -storepass ***** -storetype pkcs12 -keypass ***** -keysize 2048 -validity 3650 
-keystore /opt/arcsight/connectors/connector_1/current/user/agent/remote_management.p12 -dname CN=blablablabla,OU=blablablabla,O=ArcSight,L=NA,ST=NA,C=US ]

 

 

I know that in 7.3 this setup was barely supported but now it is since 7.6 in SyslogNGDaemonConfig.pdf - 02/15/2017 Added instructions for using a customer-supplied certificate to setup Syslog NG.

I followed it but it's the same issue.

Does anybody have this setup to compare some configuration ?

Thank you.

Cheers.

Tags (2)
0 Likes
1 Solution

Accepted Solutions
tryptyk Trusted Contributor.
Trusted Contributor.

Re: Customer-supplied Certificate override in Syslog-ng TLS Setup

Jump to solution

One update.

It is working on a different container upgraded in 7.7.

The default certificate localhost-x.x.x.x is still added to the keystore remote_management.p12 but the only noticeable change on this container is that the certificate applied contains the IP address of the container in the Subject Alternatives Names, with also the fqdn which only contained in the certificate of my problematic container.

I suppose that the TLS connect is performed on the IP address and not the fqdn and then mapped the right certificate. 

0 Likes
2 Replies
tryptyk Trusted Contributor.
Trusted Contributor.

Re: Customer-supplied Certificate override in Syslog-ng TLS Setup

Jump to solution

One update.

It is working on a different container upgraded in 7.7.

The default certificate localhost-x.x.x.x is still added to the keystore remote_management.p12 but the only noticeable change on this container is that the certificate applied contains the IP address of the container in the Subject Alternatives Names, with also the fqdn which only contained in the certificate of my problematic container.

I suppose that the TLS connect is performed on the IP address and not the fqdn and then mapped the right certificate. 

0 Likes
Community Manager COEST Community Manager
Community Manager

Re: Customer-supplied Certificate override in Syslog-ng TLS Setup

Jump to solution

All, here some more feedback that I heard from connectors team:

"Customer may have already seen this by viewing the cert using openssl, and determining that our verification process takes the value typed into the destination hostname field and compares it to the CN= of the cert for verification.

Same for TLS or not.  

For example: have a logger that customer just created the SSL cert for using the Logger System Admin page.  

That populates the CN=  to be the hostname of the device. 

If customer then takes a connector and tries to register to that logger destination as an IP address it won’t match the CN= which is a hostname. If the hostname is used then it will match and will gain success. 

Let’s just say connector is very specific about this and doesn’t store username/password to allow universal usage of such.

So what happens if hostname of the logger and included in the CN= is not resolvable?  Then the only way you can connect is via IP -- and if IP address is used then cert will fail. 

Solution for that is to add the IP hostname in the connector devices/etc/hosts file and again use the hostname when configuring the destination."

Hope this helps!

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.