Ambari website not rendering

[craftyc0der]

Going to the Ambari website gives me this error in the browser once the cluster is running. The hadoop services appear to work otherwise however.

Replacing the certificate and restarting ambari does not help. This is on GCP.

Attackers might be trying to steal your information from ... (for example, passwords, messages, or credit cards). NET::ERR_CERT_INVALID Subject: gateway Issuer: gateway Expires on: Mar 8, 2020 Current date: Mar 24, 2017 PEM encoded chain: -----BEGIN CERTIFICATE----- MIIDCzCCAfWgAwIBAgIQOpG4NhEKzcmo4x/Ep1GgBzALBgkqhkiG9w0BAQswEjEQ MA4GA1UEChMHZ2F0ZXdheTAeFw0xNzAzMjQxNTU4MDBaFw0yMDAzMDgxNTU4MDBa MBIxEDAOBgNVBAoTB2dhdGV3YXkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDYZBN3A1wsR83zumuOaNK3HnEkz3Xg7ifMcBKwwS4DsIJ6rBB7OV/cfjRr I1f/zpJs1ULG4poNyG3/Cfo57l67kNYBZhxGCCXjg/TCy1/oZLR24WwzRJ25pI0X 4B3vb8A90yREl0+9vZRfr7/XYw1f6zfc7VGSVY5XxGc13YxKh3ihe1VIbCFZUj4+ GsLGIvvmJJ+vMkk8JmeNQBkK7aQ9oL65Yd8BBmGs7B7T1jqwncoljtLDkR8xtUF5 KuImYx/uqmiw+6qUGKZIutTOUhFzHEUDTycWTbjOSoBi1nZED6UKpgHcs5KIuHZR QNZTZVFpbRZI7LcRpYxNd8PHUj05AgMBAAGjYTBfMA4GA1UdDwEB/wQEAwIAoDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAgBgNV HREEGTAXgglsb2NhbGhvc3SHBH8AAAGHBGibgcowCwYJKoZIhvcNAQELA4IBAQAb JxH4xPFI+a0R6xMxGKBXrG5jiin0lNlyziH0g781kwg4NQ+O0ICnS8GlRH123D/8 Pin4kPp4/DjnviQL9tHveXEzkO2sB/XU2//SjAjmPx0fpBQK0WXrUipsVC3cCOBJ tXFriJsx3/7F+Yhd8XrxasCpRfZ1g7RzDsot3j6Hoay1PYiwSbHvy9oG5591NWye iIGjor3zXBc94cL5Rw92mWFODQLLOR0WwN7Fv7QMCxF1cKzW1GZNxHoYI5Lv+yYh ZSrncGvZlilbINgkMQKbeTHYSPzLDOMjl6f6QTiCblwK/5nGYwBGYW5Vjm2PCJyn XtJ9EcW+UyBX92Bon/4O -----END CERTIFICATE-----

[mhmxs]

Hi @craftyc0der ,

By default we install a self signed cert for many reason. So It is ok if you get NET::ERR_CERT_INVALID. You have to add cert to the trusted certs. You mentioned you replaced the cert to an other one. What kind of cert? A self signed? Have Ambari nodes valid domain names, and valid cert for that domains?

[craftyc0der]

The cloudbreak deployer cert is also self signed and I do not have issues with making that one work. It is something specifically wrong with the Ambari cert or configuration I believe. I would encourage you to do a vanilla cloudbreak deployment with the march 24th 2017 GCP image and see if you can get Ambari to work. I've tried in multiple browsers, including curl. They all say the certificate is badly formatted. When I followed the instructions to include my own cert in Ambari, I could never get it be deployed correctly. The commands all claimed to work but my cert never was sent to my browser. This may be a second issue.

[craftyc0der]

This is the rest of the error.

You cannot visit xxx.xxx.xxx.xxx right now because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.

[craftyc0der]

I just redeployed with port 8080 open. Ambari does work without SSL.

[mhmxs]

I created a cluster with the mentioned version of Cloudbreak. What i got NET::ERR_CERT_AUTHORITY_INVALID on Chrome, and the result below with curl.

curl -I https://x.y.z.a/ambari/ --insecure
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 27 Mar 2017 16:22:37 GMT
Content-Type: text/html
Content-Length: 2012
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Last-Modified: Tue, 29 Nov 2016 20:13:22 GMT
Accept-Ranges: bytes

[craftyc0der]

I can repeat your curl and get the same response. I cannot get ANY browser to allow me to show the contents. How is the cert Ambari has different from the one that cloudbreak deployer is using which is trivial to turn off security warnings for? Pretend you where wanting to try out Cloudbreak but the demo doesn't allow you to connect to Ambari with any browser you have. What would you do?

[mhmxs]

It worked for me out of the box, i don't have to replace any cert on any node. Cloudbreak generates cert for Cloudbreak and for Ambari server too. I don't know what did you mean under Ambari website gives me this and Replacing the certificate and restarting ambari does not help and NET::ERR_CERT_INVALID. That means before replacing you got the same NET::ERR_CERT_INVALID? How did you replace? Did you restart nginx proxy?

[craftyc0der]

I have redeployed at least a dozen times (testing "recipes"). Since you can make it work "out of the box", lets ignore the cert replacement scenario and focus on the "out of box" experience. I have tried running the Ambari website from 3 different PCs (all Windows) and 10 different browsers with no luck. I get a different error than the normal "self-signed" certificate warning. Your error: NET::ERR_CERT_AUTHORITY_INVALID is different from mine: NET::ERR_CERT_INVALID in Chrome. All my computers say the certificate is malformed, not just self signed. Have you tried from Windows?

[craftyc0der]

Ambari HTTPS error. I cannot figure out how to get around this error.

Cloudbreak HTTPS error. This error is trivial to work around.

[craftyc0der]

The problem appears to be with the not quite self signed certificate on the Ambari server. Look at the error:num=20 on the cert created for Ambari. This is different from the one cloudbreak deployer shows error:num=18. At least on Windows, I can confirm that error 18 means I can use it and error 20 means I cannot. Can you confirm these results in your example deployment? Thanks for your help.

Running the following command on the ambari server yields: openssl s_client -connect localhost:443

CONNECTED(00000003) depth=0 O = gateway verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 O = gateway verify error:num=21:unable to verify the first certificate verify return:1

Certificate chain 0 s:/O=gateway i:/O=gateway

running the same command against my cloudbreak deployer server yields:

CONNECTED(00000003) depth=0 O = local verify error:num=18:self signed certificate verify return:1 depth=0 O = local verify return:1

Certificate chain 0 s:/O=local i:/O=local

[craftyc0der]

It appears the x509v3 Basic Constraint: CA must be asserted (true) is Key Usage is present now. See: https://github.com/openssl/openssl/issues/1418

See also: https://tools.ietf.org/html/rfc5280#section-4.2.1.3:

The keyCertSign bit is asserted when the subject public key is used for verifying signatures on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted.

The cert Ambari uses does not pass a verify test as shown below. $ openssl verify -CApath /etc/certs/server.pem /etc/certs/server.pem

/etc/certs/server.pem: O = gateway error 20 at 0 depth lookup:unable to get local issuer certificate

$ openssl x509 -in /etc/certs/server.pem -text -noout

X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE <-------------*****MUST BE TRUE NOW X509v3 Subject Alternative Name: DNS:localhost

[mhmxs]

For me Ambari cert also bad:

CONNECTED(00000003)
depth=0 /O=gateway
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /O=gateway
verify error:num=21:unable to verify the first certificate
verify return:1

On macos it works as well (Chrome, FF, Safari), but on windows (ie 11) not. Edge accepted Cloudbreak cert but not Ambari.

I mark issue as a bug, and hope someone would pick this up early. Thanks for the report.

[akanto]

Which version of Cloudbreak do you use? 1.6.3 or 1.14? You can check it with cbd version command.

[craftyc0der]

1.14 gs://sequenceiqimage/cloudbreak-deployer-1140-2017-03-24.tar.gz

[tanner-bruce]

This is also occurring for us, Cloudbreak 1.14.

Both Windows and Linux are able to connect to the cloudbreak deployer, however on Windows we are not able to connect to the Ambari servers, while Linux is able to.

[OlivierA]

Same issue for me from Windows/Chrome with the Cloudbreak Deployer ami-229c2f34 AMI. I have to enable the 8080 port in the AWS Security Group to bypass HTTPS.

[tanner-bruce]

@OlivierA I should have been more specific in my post.

You can also get around this by simply using Firefox on Windows, so you don't have to open up 8080