Can't get SSL certificate via API - another undocumented change?

R

Richpark

Verified User
Joined
Sep 25, 2014
Messages
50
Before the latest update, my software has been using the following API calls to retrieve SSL certificate data:

/CMD_API_SSL?domain=DOMAIN

/CMD_SSL?domain=DOMAIN&view=cacert

Now both of these calls fail with the following returned:

Unknown action, action=save is the only valid one

One question. Why? I don't see this listed in the release notes, now I have to figure out how I'm going to retrieve this information.

This update has been a nightmare from start to finish, so much of my time wasted needlessly.
 
0 problems here, both work just fine:
Code: 
/CMD_API_SSL?domain=testing%2Etld
/CMD_SSL?domain=testing%2Etld&view=cacert

I'd suggest re-checking what you send there.
 
I don't understand it then. I've been using the same call without issues for the last decade.

If I log into DA, and log into the user, and I click on the Click Here link for the CA root, I get this URL:


If I use the latest 2014 PHP API client, and I authenticate as "admin|user", and I do the following:

$sock->query("/CMD_SSL?DOMAIN=user.tld&view=cacert");

I get:

Cannot Execute Your Request
Details
Unknown action, action=save is the only valid one

The only thing I've changed since the update is switching from the ancient "fsockopen" PHP client (broken in this update) to the most recent version you link to, the 2014 "cURL" version on these forums.
 
You may start DA in debug mode and check what does it actually get in http request.
 
Thank you so much for helping with this.

I've run DA in debug mode, and I have the output for two API queries - one that works, and the one that doesn't. I'm still not clear, from the output, what the problem is:

Code: 
/CMD_API_POP
GET string: action=list&domain=the-domain.com
 0: Accept-Encoding: gzip
 1: Accept: */*
 2: Authorization: Basic REDACTED/
 3: Content-Length: 0
 4: Content-Type: application/x-www-form-urlencoded
 5: Host: localhost:2222
 6: Https: //localhost:2222
 7: User-Agent: HTTPSocket/3.0.4
 8: X-Forwarded-For: ::1
Authentication::creatorValid: got type 3 for user admin:  isDemo=0
auth.authenticated
Plugin::addHooks: start
Plugin::addHooks: end
Command::doCommand(/CMD_API_POP)
Command::doCommand(/CMD_API_POP) : finished
Command::run: finished /CMD_API_POP

Code: 
/CMD_API_SSL
GET string: domain=the-domain.com
 0: Accept-Encoding: gzip
 1: Accept: */*
 2: Authorization: Basic REDACTED/
 3: Content-Length: 0
 4: Content-Type: application/x-www-form-urlencoded
 5: Host: localhost:2222
 6: Https: //localhost:2222
 7: User-Agent: HTTPSocket/3.0.4
 8: X-Forwarded-For: ::1
Authentication::creatorValid: got type 3 for user admin:  isDemo=0
auth.authenticated
Plugin::addHooks: start
Plugin::addHooks: end
Command::doCommand(/CMD_API_SSL)
Domain the-domain.com  defaultdomain=yes usertype=1 multiple_ips=0 enable_ssl_sni=1
Dynamic(api=1, error=1):
        text='Cannot Execute Your Request'
        result='Unknown action, action=save is the only valid one<br>
'
Command::doCommand(/CMD_API_SSL) : finished
Command::run: finished /CMD_API_SSL
 
@DirectAdmin Support are you able to please look at the above debug output? It feels to me like you've put in some kind of code to distinguish between the DA panel and API requests for SSL certificate data, with API requests being disallowed access.

I can put the same API command into the DA panel's URL bar and it works fine. What's the difference? This always used to work.

The loss of this function is causing a huge amount of manual work now for our staff.
 
Hello!

Looking at the code, the only way to hit this error:
Code: 
Unknown action, action=save is the only valid one
is during a POST request. I do see "GET" in the above request type.. so my only guess currently is that the "post" is internally getting set.
If that is true, then we'd see "Post string: %s" being output at debug level 100.
If not.. then I'm not too sure (some weird memory leak setting it perhaps, but I don't think so)
This might need a ticket to debug, if you're able to create one.

What I've done, is created some extra debug code in that call. With the new binaries, if you run at exactly debug level 1245, you'll get this output:
Code: 
Command::Command::doSSL: We have POST: GET='%s' POST='%s'
where the %s bits would have what we want.
The POST should be (NULL) really, but I'm guessing it's not (as you're in a part that implies it's set to something), so I'd want to know what that is. The pre-release binaries are now available with that code:

Let us know what it says (here, or in a ticket)
 
Hi @DirectAdmin Support, thanks for looking at this.

It looks like you were right, here's the output:

Code: 
/CMD_API_SSL
GET string: domain=the-domain.com
 0: Accept-Encoding: gzip
 1: Accept: */*
 2: Authorization: Basic REDACTED
 3: Content-Length: 0
 4: Content-Type: application/x-www-form-urlencoded
 5: Host: localhost:2222
 6: Https: //localhost:2222
 7: User-Agent: HTTPSocket/3.0.4
 8: X-Forwarded-For: ::1
Authentication::creatorValid: got type 3 for user admin:  isDemo=0
auth.authenticated
Command::doCommand(/CMD_API_SSL)
Domain the-domain.com  defaultdomain=yes usertype=1 multiple_ips=0 enable_ssl_sni=1
Command::Command::doSSL: We have POST: GET='domain=the-domain.com' POST=''
Dynamic(api=1, error=1):
        text='Cannot Execute Your Request'
        result='Unknown action, action=save is the only valid one<br>
'
Command::doCommand(/CMD_API_SSL) : finished
Command::run: finished /CMD_API_SSL

I've double-checked the API script (it's the standard PHP client downloaded from this forum) and taken every step to ensure that it's a GET request, but your system is detecting "We have POST" somehow.
 
@DirectAdmin Support sorry to bump this, but have you been able to indentify why the GET request is being flagged as a POST, and subject to the "Unknown action, action=save is the only valid one" error?
 
@DirectAdmin Support can you please respond to this thread? It feels like this issue has just been abandoned now.

There is NO WAY to get the existing SSL details via the API, it no longer works. I have 13 DA servers and they're all behaving exactly the same way. I'm a DA veteran of over 15 years, I know what I'm doing with this, and the only change was your update.

I used the debug build you asked me to and posted the results above on June 21st. Can you please get this fixed so that the API is working correctly again?
 
Hello! Sorry for the delay. There might be a bug, but looking at the code, if GET is passed, the post value shouldn't be set (the "post" array should be NULL.. so not sure how it's getting there. I've tested here, but was unable to trigger the same behavior. The output shows it's empty, but not null, which .. needs to be sorted out as to why.

Anyway, if you can create a ticket, we'll be able to more easily sort out what's going on (likely requiring a root login to your box).

If you can, also ensure you've got the latest alpha binaries, as those are what I'd be testing with here, just to rule out the "it's already been fixed" possibility. I did also test with the production 1.62.4 branch, but still unable to reproduce the error with a basic CMD_API_SSL?domain=domain.com GET in a browser.

John
 
You must log in or register to reply here.
Back
Top