R80.10 GAiA Portal - Problems Importing already issued WILDCARD 2048 Certificate

[Jerry]

Hi folks

just a quick one but to some extent complicated thing: Little background though.

1. R80.10 Standalone Appliance (all-in-one) as usual
2. no PKI done for either VPN or MAB (MAB is not in use)
3. Gaia Portal has typical per-ip Cert error when you try to log in - that's normal

Research:

1. replace files at

/web/conf/server.crt
/web/conf/server.key

with your own one from your *.domain.com set (received as issued with Public CA)

based on sk109593

- result: Tomcat does not wake up at all making your GAIA portal unusable

2. replacing above files is not enough as long as your $CPDIR/conf/openssl.cnf has no CSR issued within the shell (of course not as the CSR was done separately on different device in order to make wildcard cert!)
3. I see no path for importing wildcard cert without generating csr on particular appliance - do you?

GOAL:

1. have all GAIA portal(s) from each appliance within the network using same wildcard cert already in hand from Comodo.

---

any ideas/tips/hints chaps?

much appreciate your assistance as always (PhoneBoy especially) 🙂

Cheers

Jerry

[Jerry]

Bryce,

"I try to load the .p12 from the management server first, and push it via policy -- but that doesn't work 100% of the time for whatever reason." - obviously I did the same via Portal Settings loading p12 hoping it will load at least Comodo CA to the root once - pushed and still got 192.168.1.1 on error via https

"manually load my certs using a p12 I generated without a CSR" ? how come you've had p12 without CSR from the host? please explain

trying to find out a pattern in logs for httpd2 ... bear with me ... getting into the logs just now

[Bryce_Myers]

When you pushed with the dashboard did the certificate actually make it to the apache instance?

Just because your browser received a certificate error doesn't mean that the certificate didn't make it to the UTM.  It could be giving an error based on the SAN's (Subject alternative names) specified on the certificate.  Also, keep in mind that IE sometimes doesn't interpret IPaddress SAN's correctly.

[Jerry]

fine fair enough

1. never use IE any sort with PKI issue bor with BAU

2. will find it if it made it to the Apache and let you know.

3. I can always repeat that operation and remove full PKI from shell and upload via sg properties with p12 once again

[Bryce_Myers]

Yea - you should be able to look at it from your browser as well

[Jerry]

SAN in place 

[Jerry]

look a the error in a browser Bryce, I think it is clear that CA cert is wrong and should not be issued from 192.168.1.1 plus when I see the PEM hash (server.crt) on /web/conf it is exactly that one:

[Expert@cp:0]# cat /web/conf/server.crt
-----BEGIN CERTIFICATE-----
MIIEbjCCA1agAwIBAgIJAMkM57WLXJQyMA0GCSqGSIb3D

so ... I think we're back to square one - CA root is wrong on the box and wildcard CA cert does not match with CA root somehow. How can I force CA root cert to be from the Comodo not self-signed as displayed below (in fact it is not the internal-CA one but server.crt one?

NET::ERR_CERT_AUTHORITY_INVALID

Subject: 192.168.1.1

Issuer: 192.168.1.1

Expires on: Jul 11, 2027

Current date: Aug 16, 2017

PEM encoded chain:-----BEGIN CERTIFICATE-----
MIIEbjCCA1agAwIBAgIJAMkM57WLXJQyMA0GCSqGSIb3DQEBCwUAMIGAMSEwHwYD
VQQHExhMb2NhbGl0eSBOYW1lIChlZywgY2l0eSkxFDASBgNVBAMTCzE5Mi4xNjgu
MS4xMRwwGgYJKoZIhvcNAQkBFg1F

[Bryce_Myers]

So I'm starting to remember some of the issues I've had with certificates in the past.

Can you see if the .crt and .key you have from comodo doesn't have a bunch intermediate certificates?

I've had problems with that in the past so I just use the .crt and .key with no intermediates involved.

[Jerry]

I think I got it where you coming from but I must stress out one thing Bryce - either server.crt or server.key I'm trying to load INSTEAD of using an existing one (working one) has the same sort of format and except CA root cert which is build from 2 sections of course - all those looks really similar,

original working files which gives error when using https:

1. server.crt - 26 lines

2. server.key - 28 lines 

* including -----BEGIN CERTIFICATE----- & -----END CERTIFICATE----- *

my Comodo-based files has respectively

crt - 31 lines

key - 30 lines

but ultimately I see no difference between the structure of those files really.

[Jerry]

on a side note please see the output from 

/var/log/httpd2_error_log

[Wed Aug 16 14:41:17.668330 2017] [ssl:emerg] [pid 10444] SSL Library Error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error (Type=PKCS8_PRIV_KEY_INFO)
[Wed Aug 16 14:42:22.003824 2017] [ssl:emerg] [pid 11179] SSL Library Error: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Wed Aug 16 14:42:22.003845 2017] [ssl:emerg] [pid 11179] SSL Library Error: error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error
[Wed Aug 16 14:42:22.003860 2017] [ssl:emerg] [pid 11179] SSL Library Error: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Wed Aug 16 14:42:22.003892 2017] [ssl:emerg] [pid 11179] SSL Library Error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error (Type=RSA)
[Wed Aug 16 14:42:22.003911 2017] [ssl:emerg] [pid 11179] SSL Library Error: error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA lib
[Wed Aug 16 14:42:22.003927 2017] [ssl:emerg] [pid 11179] SSL Library Error: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Wed Aug 16 14:42:22.003943 2017] [ssl:emerg] [pid 11179] SSL Library Error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error (Type=PKCS8_PRIV_KEY_INFO)

and

[Wed Aug 16 14:54:53.317854 2017] [mpm_prefork:notice] [pid 12578] AH00169: caught SIGTERM, shutting down
[Wed Aug 16 14:54:56.125071 2017] [mime_magic:error] [pid 22025] (2)No such file or directory: AH01515: mod_mime_magic: can't read magic file /web/conf/magic
[Wed Aug 16 14:54:57.000091 2017] [ssl:warn] [pid 22025] AH01906: a.b.c.d:eeee:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Wed Aug 16 14:54:57.000117 2017] [ssl:warn] [pid 22025] AH01909: a.b.c.d:eeee:0 server certificate does NOT include an ID which matches the server name
[Wed Aug 16 14:54:57.014244 2017] [so:warn] [pid 22025] AH01574: module setenvif_module is already loaded, skipping
[Wed Aug 16 14:54:57.014265 2017] [so:warn] [pid 22025] AH01574: module headers_module is already loaded, skipping
[Wed Aug 16 14:54:57.017629 2017] [core:warn] [pid 22025] AH00117: Ignoring deprecated use of DefaultType in line 420 of /web/conf/httpd2.conf.
[Wed Aug 16 14:54:57.017894 2017] [mime_magic:error] [pid 22025] (2)No such file or directory: AH01515: mod_mime_magic: can't read magic file /web/conf/magic
[Wed Aug 16 14:54:58.000975 2017] [ssl:warn] [pid 22025] AH01906: a.b.c.d:eeee:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Wed Aug 16 14:54:58.001005 2017] [ssl:warn] [pid 22025] AH01909: a.b.c.d:eeee:0 server certificate does NOT include an ID which matches the server name
[Wed Aug 16 14:54:58.005287 2017] [mpm_prefork:notice] [pid 22025] AH00163: CPWS/2.4.16 (Unix) OpenSSL/1.0.1p configured -- resuming normal operations
[Wed Aug 16 14:54:58.005325 2017] [core:notice] [pid 22025] AH00094: Command line: '/web/cpshared/web/Apache/2.2.0/bin/httpd2 -f /web/conf/httpd2.conf -D FOREGROUND'

really confusing but I tried to fix that by regen the default certs for Gaia Portal - no luck, after that Portal stopped working completely and my aim was obviously only to replace default with my own keys ...

any idea boys and girls ?

[Jerry]

Bryce, what I've got all CA root's from Comodo like those:

addtrustexternalcaroot.crt

comodohigh-assurancesecureserverca.crt

ca-bundle.crt

I've load them as CA Server's by Dash to the OPSEC by selecting 3rd party - still after Apache restart - same thing

[Jerry]

[Wed Aug 16 15:09:24.000834 2017] [ssl:warn] [pid 1453] AH01906: ______________ server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Wed Aug 16 15:09:24.000864 2017] [ssl:warn] [pid 1453] AH01909: ______________ server certificate does NOT include an ID which matches the server name

and again on the loading page whilst https via chrome I can see:

NET::ERR_CERT_AUTHORITY_INVALID

Subject: 192.168.1.1

Issuer: 192.168.1.1

Expires on: Jul 11, 2027

Current date: Aug 16, 2017

PEM encoded chain:-----BEGIN CERTIFICATE-----
MIIEbjCCA1agAwIBAgIJAMkM57WLXJQyMA0GCSqGSIb3DQEBCwUAMIGAMSEwHwYD
VQQHExhMb2NhbGl0eSBOYW1lIChlZywgY2l0eSkxFDASBgNVBAMTCzE5Mi4xNjgu
MS4xMRwwGgYJKoZIhvcNAQkBFg1FbWFpbCBBZGRyZXNzMScwJQYJKoZIhvcNAQkC
.....................................
-----END CERTIFICATE-----

ps. I do not use 192.168.1.1 as a CA, as an Object nor devices has that IP address configured ANYWHERE within the entire configuration of All-in-One Standalone deployment.

What is the weirdest here that this above thumbprint is precisely the same (hash wise) as the /web/conf/server.crt file content ...

much appreciate your time and effort folks, you always rocks and you still do

[PhoneBoy]

CA = TRUE would suggest that this is a CA key.

Meaning the key is meant to be used for signing other keys, it can't be used for a server like this.

There are various things on Google that suggest how to fix this for self-signed certificates.

I'm guessing for a cert from Comodo, you might have a harder time with that.

[Jerry]

I guess you right but on the other hand I'm not desperate to get the Gaia Portal on wildcard Comodo cert. It's just an option which would be great if I polish that before talking to the customer(s)

It's not super urgent for me to make the trusted CA over the Gaia Portal but again - no tension no pressure it's all down to some wired and unexplored for me conflicts with the ROOT CA which acts like it has an old (from the installation time) hashes and made them server.crt from the /web/conf on not configured IP address 192.168.1.1 - this is what gets me and bother me the most and as mentioned earlier it is just super intriguing why and how come we all cannot get this sorted by replacing .crt and .key in one folder as explained by CP R&D by sk. 

[Bryce_Myers]

You are right - you should be able to manually load an ssl cert/key combo.

It looks like there is some type of conflict when the apache instance tries to load those files.  I wouldn't worry too much about the ssl:warn messages, as I think apache should still work with warnings.

The conflict could be corrupted cert/key files or if there is some type of mismatch.  Have you ever tried to load this cert/key combo on just a standard Apache instance without Checkpoint involved?  I'm thinking you would run into the same errors.

It looks like both your of your files are in PEM format right?  You showed your .cert --BEGIN CERTIFICATE -- does your .key just contain --BEGIN RSA PRIVATE KEY-- ?

[Bryce_Myers]

Also - just to make sure.  Are you running another other blades on this standalone?  I've noticed some weird things with the /web/conf/ cert and key files when running Identity Awareness for example (which also shares the apache instance)

[Jerry]

Nop. There is no IA or anything else. That devices holds only FW and IPS. That’s all.

Reg. Certs – all BEGINNING and END’s are correct. No suspicious into the files.

The original certs witch work (those giving you 192.168.1.1 and ERROR message in Chrome) are same patter as mine from Comodo.

Super wired, isn’t it? I’m really thinking to give on this but shall we really do that?

[Bryce_Myers]

Never give up!

When you open the crt in Windows - Does it show the full certification path?

Also does comodo give you the option to download the whole pack in a pcks like .p12 format?

[Jerry]

ad1 - I don't understand the question, I can open CRT file by any platform and it looks identical ?

ad2 - NO, p12 I've made myself by typical openssl commands using since 20y with CP products on bash

[Bryce_Myers]

So have you just generated your own wildcard certificate to verify you can at least manually update the Webui?

      This way we can take the comodo part out of the equation (Sorry if you've already done this)

         From a Unix platform with openssl:

openssl genrsa 2048 > host.key
openssl req -new -x509 -nodes -sha1 -days 3650 -key host.key > host.crt
#[enter *.domain.com for the Common Name]
openssl x509 -noout -fingerprint -text < host.cert > host.info

Then just backup yorur server.crt and server.key and replace it with the .crt and .key you self-generated and restart httpd2 like I mentioned previously.

[Jerry]

Bryce,

I've made the wildcard cert making the csr towards Comodo CA on one of my gaia's r80.10 appliances but but the one I'm trying to import keys onto but that's irrelevant.

I've just generated csr and completed the chain having all the files from that process handy. p12 I've made afterwards in order to import it via Dash (as usual) towards the Gaia Portal and MAB (different appliance). So essentially I've completed the PKI on one device and now making another with Gaia Portal on wildcard certificated - and here is the issue I guess.

Answering your question then, "have you just generated your own wildcard certificate to verify you can at least manually update the Webui" => No. That is not the point Bryce.

As mentioned earlier I've made the full PKI for Comodo Wildcard cert in order to have it spread all around my linux-based devices where I could utilize it on Apache's/Tomcats as well as on other Gaia based devices i.e. Gaia Portal's on variety of my R80.10's all around my network. That's all I wanted to achieve really. So if having the p12 or component files (pem based) does not give me an option to replace server.crt and server.key files with respective copies I've got already in hand - then how can I make any "another"  Gaia Portal on "another" R80.10 using my wildcard?

The whole purpose of the wildcard certificate is to have it used on multiply platform completing just the PKI chain by importing either PEM or PCKS-type of files onto the shell (platform) - isn't that obvious?

One question though. If I use:

openssl genrsa 2048 > host.key openssl req -new -x509 -nodes -sha1 -days 3650 -key host.key > host.crt 

#[enter *.domain.com for the Common Name]
openssl x509 -noout -fingerprint -text < host.cert > host.info

on the platform where I've got no PKI chain yet completed

would that work fine on GAIA Portal httpd2 with /web/conf files?

Jerry

[Bryce_Myers]

Jerry --

I see that it is obvious what you are trying to do -- The end goal being to utilize this Wildcard Comodo certificate throughout your checkpoint gaia webui infrastructure, correct?  I'm simply trying to break down the different parts to help clarify where the issue is occurring, which may point us in the right direction to solve/workaround it.

So I see mulitple parts to the issue and I'm just trying to understand your focus (I think I understand the end goal)

• .p12 from SmartDash
  • Are you concerned that you can't push any .p12 down to the Gaia Portal from SmartDash?
  • Or You've pushed OTHER .p12 files down - just not this particular Wildcard Comodo certificate
• Certificates on the Webui
  • Can you get any certificates to load on the WebUI? 
  • Or you can get certificates to load manually (.crt, .key) but you can't get this WildCard Comodo Certificate chain to load to the webUI

I'm not trying to complicate anything, I'm just trying to get a full picture of the errors you're having with the certificates.

[Jerry]

Brilliant so we're on the same page Bryce. Thank you. You are correct with most of the investigation steps but I'm also trying to understand the logic of your advises hence my quite distanced answers my apologize, I'll simplify all this by one thing I guess. One answer though: 

• .p12 from SmartDash
  • Are you concerned that you can't push any .p12 down to the Gaia Portal from SmartDash?
  • Or You've pushed OTHER .p12 files down - just not this particular Wildcard Comodo certificate

*** When I make p12 via Dash to the Gateway it works and it works on the platform where CSR was generated (MAB wise not Gaia Portal)

*** I have only used one wildcard p12 on few of my r80.10 and it works only via MAB on one of them, but shows all correct via Dashboard object settings

• Certificates on the Webui
  • Can you get any certificates to load on the WebUI?
  • Or you can get certificates to load manually (.crt, .key) but you can't get this WildCard Comodo Certificate chain to load to the webUI

*** I just tried and they work (see my prev. post) but still showing this isn't private connection so no CA mach I guess

*** I cannot get that particular wildcard Comodo to work on my few Gaia's that's all. Have no tried other as this is my first wildcard on this infra. That's all.

[Jerry]

I've made your suggested new set:

-rw-r--r-- 1 j j 1310 Aug 17 21:31 host.crt
-rw-r--r-- 1 j j 3163 Aug 17 21:31 host.info
-rw-r--r-- 1 j j 1679 Aug 17 21:30 host.key

now, if I put this to the GAIA /web/conf folder and replace server.crt and server.key with those above listed files - how it is suppose to start httpd2 ?

I think I don't get the point here (no CSR was in use on that openssl just .info file so with all due respect I see no logic how this would potentially heal my problem.

Please explain if you can and don't want to give up yet

J.

[Bryce_Myers]

Jerry --

You are correct I don't think this will heal your problem.  I just want to make sure we can get any new cert/key combo to work on you GAIA web UI.  If this cert/key combo works, then we need to investigate how checkpoint is reading your wildcard certificate/key combo.

If you place that host.crt as the file /web/conf/server.crt and place the host.key as the /web/conf/server.key and restart httpd2 (tellpm process:httpd2 -- tellpm process:httpd2 t) then I would expect you to see the new details in the web browse after a refresh.

[Jerry]

hence I've answered already - it shows this:

Your connection is not private

Attackers might be trying to steal your information from cp.checkpoint.xxx (for example, passwords, messages, or credit cards). Learn more

NET::ERR_CERT_AUTHORITY_INVALID

Subject: *.checkpoint.xxx

Issuer: *.checkpoint.xxx

Expires on: Aug 15, 2027

Current date: Aug 17, 2017

PEM encoded chain:-----BEGIN CERTIFICATE-----
MIIDmzCCAoOgAwIBAgIJAKrmRPTtBnqfMA0GCSqGSIb3DQEBBQUAMGQxCzAJBgNV
BAYTAkdCMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQxHTAbBgNVBAMMFCouY2hlY2twb2ludC5uZXR3b3JrMB4X
-----END CERTIFICATE-----

[Jerry]

[Bryce_Myers]

Ok great -- That atleast shows us that your Web management GUI can take a certificate.

In my experience with checkpoint -- SmartDashboard struggles to push .p12 files down to the gateway unless you're using a multi-portal blade like Identity Awareness / Captive Portal.  So you may have to load the Comodo certificate manually when we figure out how to get it loaded.

But lets continue on with your issue and see if we can figure out why your Comodo Wildcard Certificate won't load.  So when I had problems with similar errors in the past it had to do with the way Checkpoint's Apache was trying to load the certificate and key.  Sometimes this is because either they aren't a pair or I've seen issues in the past where my RSA key encrypted with a passphrase and I didn't know it.

Lets verify your Comodo RSA Key isn't encrypted:

The "RSA key" is actually a set of values stored as an ASN.1 structure in the standardized DER binary format, then encoded in base-64 to get the final PEM file.

A very easy way to determine whether a key is encoded or not is simply to check whether the ASN.1 header is present, and this is usually as simple as checking if the "key" begins with the letters MII as in the example below:

-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQCWxk9djtgA/t7n6M8g1d2fk3exyCSu1uubpxUkoFLJBKjLYiaa
[...]
eCrpRFHxhPICHI4db+I8GZ9QDmlbCN/bl3BBNNTn3w==
-----END RSA PRIVATE KEY-----

[Jerry]

all my keys begin always from MII indeed

[Bryce_Myers]

We are just talking about the 1 RSA key for your comodo certificate right?

Also - can you take a look at the comodo .crt file and ensure it is un-encrypted using the same method?

[Jerry]

correct- one cert one key one root CA cert one RSA hash all along