API login authentication issue

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: kituthegreat.tk

I ran this command: kituthegreat.tk/api/v1/account/register

It produced this output:

Error
Cannot GET /api/v1/account/register

My web server is (include version): nginx/1.10.3 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu 16.04.6 LTS

My hosting provider, if applicable, is: AWS

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.31.0

I am running the same API on local server that is not encrypted with certbot and able to register OK. I get this response:
Successfully created new account

All other API access points are working fine.

Thanks
When I run the same command on the local server

Hi @kituthegreat,

I'm not sure I understand what you mean here. What is the certbot command that you ran? Why do you have an ACME v1 URL under the domain name you're trying to issue a certificate for?

I do not run any certbot commands. I already issued a certificate for my site and it is working OK. The issue is that after I applied certbot and able to access my site via https, I am no longer can register accounts in my site.

Ahh, I understand now.

Cannot GET /api/v1/account/register

Are there any server-side nginx logs that match the failed requests?

What software is emitting this error?

I don’t see any problems with the certificate chain being presented by kituthegreat.tk

1 Like

I would have to check on the webserver logs and get back to you. API is running on nodejs and using passport package for authentication. Thx.

Thanks,

Vlad

1 Like

From the description it looks more like an origin or mixed content problem. If you have switched your site to HTTPS and accessing the pages where some content is still loaded/referenced via HTTP, that will not work.

2 Likes

I checked both access and error log and didn’t see anything specific that would match failed request.

1 Like

I don’t see any references to HTTP in the API. Here is the GITHUB link to the API:

account.js is where I have configured access to the page that is failing. I am pretty sure I was able to register account via this page before I switched to HTTPS.

1 Like

Hi @kituthegreat

your main configuration is ok - Grade B is very good ( https://check-your-website.server-daten.de/?q=kituthegreat.tk ):

Domainname Http-Status redirect Sec. G
http://kituthegreat.tk/
54.187.173.112 301 https://kituthegreat.tk/ 0.353 A
https://kituthegreat.tk/
54.187.173.112 200 2.390 B

And there is no mixed content.

But checking the https manual, there is the standard nginx page - "Welcome to nginx". Is this correct?

Perhaps you have more then one port 80 vHost, Certbot has picked the wrong vHost as template to create the port 443 vHost.

What says

nginx -T

“Welcome to nginx” is a correct default page.

I get this:

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

1 Like

I need the -T, not -t. That shows more informations.

I think this is probably a problem with your application, not with the changes that Certbot made to your Nginx configuration. Here's why: When I fetch the URL you provided, I get a header that says X-Powered-By: Express. Express is the Node.js application framework you're using. That means that the request was sent to your application, and your application responded with 404.

$ curl -iL https://kituthegreat.tk/api/v1/account/register
HTTP/1.1 404 Not Found
Server: nginx/1.10.3 (Ubuntu)
Date: Fri, 28 Jun 2019 19:07:56 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 162
Connection: keep-alive
X-Powered-By: Express
Content-Security-Policy: default-src 'none'
X-Content-Type-Options: nosniff

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot GET /api/v1/account/register</pre>
</body>
</html>

By comparison, if I fetch https://kituthegreat.tk/other-url, I do not see the X-Powered-By header, meaning this request was handled purely by Nginx:

$ curl -iL https://kituthegreat.tk/other-url
HTTP/1.1 404 Not Found
Server: nginx/1.10.3 (Ubuntu)
Date: Fri, 28 Jun 2019 19:09:42 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive

<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.10.3 (Ubuntu)</center>
</body>
</html>

Looking at your application code, I see that the account/register endpoint only implements POST, not GET, which is probably why you're getting this error. If you use POST you get a different error:

$ curl -iL https://kituthegreat.tk/api/v1/account/register -X POST
HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Fri, 28 Jun 2019 19:13:34 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 65
Connection: keep-alive
X-Powered-By: Express
ETag: W/"41-qZyyaoYQCUNS5XaTsU9PjlXufmE"

{"name":"MissingUsernameError","message":"No username was given"}

Good luck debugging your application! I'm afraid that's as far as I can help you on it.

1 Like

By the way, if you want to prove to yourself that the problem is not any changes made by Certbot, you can run:

certbot rollback --checkpoints 1000

Which will roll back any changes Certbot has made to your Nginx config. Note that this will also rollback any manual changes you have made to your config since the time you ran Certbot.

1 Like

This is very interesting. I am using Postman. Definitely using POST for this endpoint and getting :

Error
Cannot GET /api/v1/account/register

I also notices that you specifically use https://kituthegreat.tk/api/v1/account/register
I was using just kituthegreat.tk/api/v1/account/register
It was working fine for GET requests, so I assumed I could use it for everything. As soon as I changed to https://kituthegreat.tk/api/v1/account/register in the Postman, everything started to work.
When I tested the same Github repo on a machine without https, using kituthegreat.tk/api/v1/account/register was not an issue.

Issue is resolved. Thank you very much everybody.

http://kituthegreat.tk/api/v1/account/register returns a 301 redirect to https://kituthegreat.tk/api/v1/account/register.

According to the HTTP standard:

Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.

If your HTTP implementations are modern enough, you can use the newer 308 redirect to make the subsequent request use POST. For compatibility with somewhat older implementations, you could use a 307 temporary redirect instead.

Honestly, though, since POSTing information over HTTP isn’t secure at all, it might be better to have things break in an obvious way instead of continuing to work insecurely.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.