Certbot unauthorized and connection errors - spring-boot

I have a spring boot application on Google Cloud, CentOS 7. I wish to install SSL certificate via Let's Encrypt and Certbot. When I use certbot --apache -d mydomain.zone command I receive an error:
My domain is registered on Namecheap. My A records on Google Cloud:
Also I provided google cloud nameservers in Namecheap like in this tutorial: https://www.wpmentor.com/setup-domain-google-cloud-platform/
Can you tell me where the issue is? I also wonder is there an issue with my java code in app. For example sometimes while accessing index page, error_page is called. When I have a method in my controller:
#RequestMapping(value = "/error_page", method = RequestMethod.GET)
public String homeError(Model model)
{
return "/error_page";
}
I have a different certvbot error:
but when I comment/erase my controller method for error page I receive this error:
Can it be it's an application bug? Or issue with apache?
EDIT:
I tried to turn off Tomcat. Now I receive this error:
note: My Apache forwards to 8080, I don't know will it make any issue?
iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080
After curl -I -L http://mydomain/.well-known/acme-challenge/zySNHSFB-qL95Ubx4jcIvuHPiiNbwkphE55kFuqP8jM:
HTTP/1.1 302
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Location: /error_page
Content-Language: en-US
Content-Length: 0
Date: Tue, 15 Feb 2022 20:01:50 GMT
HTTP/1.1 302
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Location: /error_page
Content-Language: en-US
Content-Length: 0
Date: Tue, 15 Feb 2022 20:01:50 GMT
curl: (47) Maximum (50) redirects followed

I needed to turn off the Apache web server to free my port 80. Also, I deleted iptables rule that forwards traffic from port 80 to port 8080. Now Certbot works

Related

wget gives 403 on accessible files

First time poster with a bizarre issue I am having. I usually install software through conda, but from one moment to the other I stopped being able to use conda install because of a 403 I get from conda trying to access some configuration files. When trying to download those files with wget --spider --debug https://conda.anaconda.org/anaconda/noarch/current_repodata.json, I get the same 403 error.
DEBUG output created by Wget 1.19.4 on linux-gnu.
Reading HSTS entries from /home/jsequeira/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'current_repodata.json' (UTF-8) -> 'current_repodata.json' (UTF-8)
Spider mode enabled. Check if remote file exists.
--2020-07-30 11:25:59-- https://conda.anaconda.org/anaconda/noarch/current_repodata.json
Resolving conda.anaconda.org (conda.anaconda.org)... 104.17.92.24, 104.17.93.24, 2606:4700::6811:5d18, ...
Caching conda.anaconda.org => 104.17.92.24 104.17.93.24 2606:4700::6811:5d18 2606:4700::6811:5c18
Connecting to conda.anaconda.org (conda.anaconda.org)|104.17.92.24|:443... connected.
Created socket 5.
Releasing 0x000056545deb1850 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 5 to SSL handle 0x000056545deb2700
certificate:
subject: CN=anaconda.org,O=Cloudflare\\, Inc.,L=San Francisco,ST=CA,C=US
issuer: CN=Cloudflare Inc ECC CA-3,O=Cloudflare\\, Inc.,C=US
X509 certificate successfully verified and matches host conda.anaconda.org
---request begin---
HEAD /anaconda/noarch/current_repodata.json HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: conda.anaconda.org
Connection: Keep-Alive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 403 Forbidden
Date: Thu, 30 Jul 2020 11:25:59 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
CF-Chl-Bypass: 1
Set-Cookie: __cfduid=d3cd3a67d3926551371d8ffe5a840b04f1596108359; expires=Sat, 29-Aug-20 11:25:59 GMT; path=/; domain=.anaconda.org; HttpOnly; SameSite=Lax
Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 01 Jan 1970 00:00:01 GMT
X-Frame-Options: SAMEORIGIN
cf-request-id: 044111dd9600005d4732b73200000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Vary: Accept-Encoding
Server: cloudflare
CF-RAY: 5baeb8dc2ba65d47-LIS
---response end---
403 Forbidden
cdm: 1
Stored cookie anaconda.org -1 (ANY) / <permanent> <insecure> [expiry 2020-08-29 11:25:59] __cfduid d3cd3a67d3926551371d8ffe5a840b04f1596108359
URI content encoding = ‘UTF-8’
Closed 5/SSL 0x000056545deb2700
Remote file does not exist -- broken link!!!
These files are accessible through the browser, and were always accessible with wget and conda until yesterday, when I was installing some tools not related to these network accesses. How can wget fail to download them?
So this was fixed by reinstalling apt-get. Some configuration file there must have been messed up.

How to do a proper handshake with the Coinbase Websocket for Market Data?

What is the first HTTP request I should send for a proper websocket handshake?
I am sending GET / HTTP/1.1 with some other standard websocket headers but I get a 400 Bad Request. See below
$ telnet localhost 8889
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
GET / HTTP/1.1
Host: ws-feed.exchange.coinbase.com
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://www.test.com
HTTP/1.1 400 Bad Request
Server: cloudflare-nginx
Date: Thu, 10 Sep 2015 19:25:54 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d3fe870c84fc991b0f2f6fc2c936820471441913154; expires=Fri, 09-Sep-16 19:25:54 GMT; path=/; domain=.coinbase.com; HttpOnly
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
X-Content-Type-Options: nosniff
CF-RAY: 223d857c6bae01ee-EWR
0
Sec-WebSocket-Version header and Sec-WebSocket-Key header are missing.

How to cache API calls via Varnish?

My goal is to cache RESTful API calls via Varnish. AS I was reading on stackoverflow and other resources, Varnish can not cache post requests. This is exactly what I am experiencing. Therefore I moved to get with ?id=30 but then I realized that those also do not get cached because of the question mark.
So the question is, how o cache API-Calls over Varnish?
Here are two example calls to my API, secured by Oauth2 with 2 parameters pased by post:
curl --insecure -s -k https://test-api/v1/test -d 'access_token=72f50e68a0aed7921c6cb058de8e7e6ed4ebd692&clid=585970' -D- -o/dev/null
HTTP/1.1 200 OK
Date: Sat, 29 Aug 2015 13:02:36 GMT
Server: Apache/2.2.31 (Unix) PHP/5.6.11
X-Powered-By: PHP/5.6.11
Vary: Accept-Encoding
Content-Length: 2121
Content-Type: application/json
X-Varnish: 6558010
Age: 0
Via: 1.1 varnish-v4
Accept-Ranges: bytes
Set-Cookie: SERVERID=S3; path=/
curl --insecure -s -k https://test-api/v1/test -d 'access_token=72f50e68a0aed7921c6cb058de8e7e6ed4ebd692&clid=585970' -D- -o/dev/null
HTTP/1.1 200 OK
Date: Sat, 29 Aug 2015 13:02:56 GMT
Server: Apache/2.2.31 (Unix) PHP/5.6.11
X-Powered-By: PHP/5.6.11
Vary: Accept-Encoding
Content-Length: 2121
Content-Type: application/json
X-Varnish: 12814168
Age: 0
Via: 1.1 varnish-v4
Accept-Ranges: bytes
Set-Cookie: SERVERID=S2; path=/
Is it possible to configure Varnish to cache the API calls? POST/GET either way I don't mind.

Drive Realtime API no longer returns realtime document on localhost

I have been calling the following gapi javascript function with great success for a few months:
gapi.drive.realtime.load(fileId,
successHandler,
initializer,
errorHandler);
Suddenly, at 1:30 PM CDT today, that call stopped working when run in javascript on localhost. I can deploy the exact same code to my server and it works perfectly!
Frustratingly, none of the callbacks are called - not successHandler OR errorHandler.
I have localhost:3000 set as an allowed javascript origin in my Google API Console project, and anyway I haven't changed any settings there since this was working. I am correctly authorized and can make REST calls to the Drive API without an issue.
Has anyone else seen this behavior suddenly? Can anyone from the Google team make a suggestion?
Update: the request inspector shows a GET to
https://drive.google.com/otservice/gs?access_token=[ommitted-for-stackoverflow]&id=[also-omitted]
with the response
)]}'
["17AKDsTY8kHESKfQavrHeh3YybD5k4b6ty8CQ78MHtyc","724b79b808d48070",false,1,[1,""],[0,[28,"724b79b808d48070","110581799581534438628",false,true,"REL DEV","#58B442","https://lh3.googleusercontent.com/-XdUIqdMkCWA/AAAAAAAAAAI/AAAAAAAAAAA/4252rscbv5M/s128/photo.jpg"]]]
The headers are
HTTP/1.1 200 OK
status: 200 OK
version: HTTP/1.1
access-control-allow-origin: *
access-control-expose-headers: Content-Length,Content-Type,X-Restart
alternate-protocol: 443:quic
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-disposition: attachment; filename="json.txt"; filename*=UTF-8''json.txt
content-encoding: gzip
content-type: application/json; charset=utf-8
date: Fri, 04 Apr 2014 22:15:40 GMT
expires: Fri, 01 Jan 1990 00:00:00 GMT
pragma: no-cache
server: GSE
vary: Origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-restart:
x-xss-protection: 1; mode=block
There are no other requests after that.

Passenger Unknown Reason-Phrase

When I try to access my site throught main domain (example.com) I get message like below. But it doesn't happen if I access the my site through a subdomain. I'm using Passenger with Nginx. Any ideas on how I can fix this? Thanks!
HTTP/1.1 16797828 Unknown Reason-Phrase
Status: 16797828 Unknown Reason-Phrase
Content-Type: text/html;charset=utf-8
Content-Length: 0
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Powered-By: Phusion Passenger 4.0.20
Date: Mon, 21 Oct 2013 09:06:42 GMT
It's because your app returned an invalid HTTP response code (namely '16797828'). You should fix your app not to do that.

Resources