Update Certificate Subdomain Check Fails For Some CURL Versions

[markfennema]

The update-loggly-certificate.sh script uses a grep "200 OK" check to see if a subdomain exists. However, some versions of CURL have the following output instead:

HTTP/2 200
date: Fri, 06 Apr 2018 13:46:05 GMT
content-type: text/html; charset=utf-8
server: Apache/2.2.22 (Ubuntu)
content-security-policy: frame-ancestors 'none'
expires: Fri, 06 Apr 2018 13:46:05 GMT
vary: Cookie,Accept-Encoding
last-modified: Fri, 06 Apr 2018 13:46:05 GMT
x-loggly-page: login
cache-control: no-cache, no-store, must-revalidate, max-age=0
x-frame-options: DENY
x-loggly-request-uuid: APP453591de-1cee-4395-8bd9-e2fc03b7eb31
set-cookie: csrftoken=qULhsGspdY7UyVV6CsdQx5atdDoHHB5S; expires=Fri, 05-Apr-2019 13:46:05 GMT; Max-Age=31449600; Path=/
x-varnish: 426339233
age: 0
via: 1.1 varnish-v4
accept-ranges: bytes

Note that it simply states 200 rather than 200 OK.

The grep command could easily be modified to work with this version of CURL as well.

[Shwetajain148]

Hi @markfennema, do you want the updated check to be looks like- https://github.com/loggly/install-script/blob/master/Linux%20Script/configure-linux.sh#L357 so that the script passes the subdomain if the response is either 200 or 200 OK, is that right?

Also, do you mind sharing your setup in which you are using this update-loggly-certificate.sh script?

Thanks for the additional information.

[markfennema]

That looks great to me.

I'm on vacation right now, so I'm out of the office (and am not sure off the top of my head the exact details of the environment it was failing on), but I'll get back to you next week.

[markfennema]

Here is the curl version information:

curl 7.53.1 (x86_64-redhat-linux-gnu) libcurl/7.53.1 NSS/3.28.4 zlib/1.2.8 libidn2/0.16 libpsl/0.6.2 (+libicu/50.1.2) libssh2/1.4.2 nghttp2/1.21.1
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy PSL

The machine is running Amazon Linux AMI release 2016.09

[Shwetajain148]

Hi @markfennema, Sorry for the late reply. So I checked on the Amazon Linux AMI machine and verified the curl output of the login command and could see the same output as you pasted in your first comment. See below-

[ec2-user@ip-172-31-29-21 ~]$ curl -s --head  --request GET https://mylabenv.loggly.com/login
HTTP/2 200
date: Tue, 15 May 2018 11:16:19 GMT
content-type: text/html; charset=utf-8
server: Apache/2.2.22 (Ubuntu)

The weird thing that I noticed was in the GitHub code it is grep "200 OK" at line #306 but when you download this script on your machine and see the code it is grep "200" at the same line.

Being grep "200", currently passes the subdomain check for both responses- "200 OK" and "200". I tested on 2 machines with both response codes and the script didn't break/failed for subdomain check.

Also, can you please check and let me know how did you come to know that it is breaking so that I can test as well?

Thanks for your input.

[markfennema]

I followed the instructions on this page: https://www.loggly.com/docs/upgrade-tls-certificate/

But I double checked that file and now it's fixed. It definitely was the 200 OK version when I downloaded it in April (or else I never would have found the issue).

[Shwetajain148]

Hello @markfennema, Since now it's fixed for you I'll just update the GitHub code to- grep "200" so that it doesn't confuse anyone and will be the same as deployed script code. I'll close the issue once I update it.

Thanks.

[Shwetajain148]

Since it has already been handled, closing this issue.