Issue stat(): SSL operation failed with code 1.

[Sysop]

I'm trying to access an external FTP with TLS/SSL through PHP and receive an error:

stat failed for ftps://xxx:[email protected]:2222/ at  /var/www/vhosts/website/httpsdocs/nextcloud/apps/files_external/lib/Lib/Storage/StreamWrapper.php#127 | 2017-08-14T19:09:26-0700

Error | PHP | stat():  SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate  verify failed at  /var/www/vhosts/website/httpsdocs/nextcloud/apps/files_external/lib/Lib/Storage/StreamWrapper.php#127

I'm really not certain how to fix the issue. From what I can tell I've got a valid SSL ( letsencrypt ) installed on the subdomain that is trying to access the external FTP. Any suggestions would be appreciated - thanks.

 

[UFHH01]

Hi Sysop,

try to solve your "openssl" ( NOT Plesk related ) issue with for example:

For CentOS/RHEL based systems:

yum install ca-certificates.noarch

For Debian/Ubuntu based systems:

aptitude install ca-certificates

followed by

update-ca-certificates

In addition, pls. note two things:
It is recommended to provide MORE informations if you need help from the Plesk Forum Community. You sould at least provide YOUR current operating system and YOUR current used Plesk version ( incl. #MU ) and pls. keep in mind, that non - Plesk - related issues/errors/problems/discussions should be done at:

=> Home > Forum > General Discussion > Open Topics​

 

[Sysop]

Hi UFHH01,

I realize it's not necessarily Plesk related, although I'm not sure why the error exists in the first place. The certificate you mentioned is already installed:

$ yum install ca-certificates.noarch
Package ca-certificates-2017.2.14-70.1.el7_3.noarch already installed and latest version
Nothing to do

Here are the machine specifics:

$ cat /proc/version
Linux version 3.10.0-514.21.1.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Thu May 25 17:04:51 UTC 2017
# cat /usr/local/psa/version
17.5.3 CentOS 7 1705170317.16
# php --version
PHP 5.4.16 (cli) (built: Nov  6 2016 00:29:02) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
    with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.0.18, Copyright (c) 2002-2015, by ionCube Ltd.

The version of PHP that is running on the subscription with the issue is version 7.0.21

 

[Bitpalast]

It could simply be caused by a wrong certificate on the FTP server, for example if the certificate was made out to domain A and you are addressing the server by domain B.

 

[Sysop]

Hi Peter,

I think you're probably correct on this; would I point to the correct certificate via a directive in the PHP settings? If so how? Thank you.

 

[Bitpalast]

You cannot select the certificate by a PHP directive. The FTP server must provide the correct certificate for the domain name that you use to address the FTP server. If the domain name of the certificate on the FTP server is different from the domain name that you are using to open the FTP connection, the certificate error appears. You must either have a certificate in place for the domain name you are using to establish the FTP connection or you must change the domain name that you are using to establish the connection to the domain that the certificate on the FTP server is using.

 

[Sysop]

I have a valid letsencrypt SSL certificate in place for the domain associated with the FTP although Plesk wants to use the default domain name's certificate for whatever reason. I'm thinking that the following directive should work:

openssl.cafile=/path/to/cert.pem

I'm just not sure where the path is just yet, or if it'll even work. I'm still confused why Plesk would be using the wrong certificate though... thanks!

 

[Bitpalast]

All FTP connections to and from a server are using the server's host name and host name certificate. The domain name certificate of domains and subscription is not used for FTP, because the FTP service is configured on the host computer, not on a single domain. In that case you must use the host computer's domain name.

 

[Sysop]

There's definitely some strange issues happening, here's the first part:

I manually had to add the letsencrypt certificate on domain.local because of an error when going through Plesk:

Error: Let's Encrypt SSL certificate installation failed:
Invalid response from https://acme-v01.api.letsencrypt.org/acme/new-authz: Error creating new authz :: Name does not end in a public suffix. Type: urn:acme:error:malformed.

Apparently Plesk doesn't know how to fully handle a local suffix subscription name like domain.local. ( sub.domain.com alias points to domain.local ). sub.domain.com has a valid letsencrypt certificate.

When I try and navigate to Home > Tools & Settings > SSL/TLS > View I get redirected to "pleskdomains.com", the actual link is "https://mydomain:8443/admin/mpc/view-certificates" > redirects to pleskdomains.com.

Also on the same page it shows I'm using the letsencrypt cert ( serverpool ), although in the listing below it says I'm not using it... so it's quite confusing.

Probably unrelated:

AH01909: RSA certificate configured for domain.local:443 does NOT include an ID which matches the server name

 

[mr-wolf]

.local certificates are not issued anymore by CA's (several years already). They are both silly as a security issue.
Older Microsoft servers ask for them in their CSR's when running the SSL wizard.


I have no idea what you're trying to do.
Your posts are confusing, this part of Plesk is not

 

[Sysop]

.local certificates are not issued anymore by CA's (several years already). They are both silly as a security issue.
Older Microsoft servers ask for them in their CSR's when running the SSL wizard.

I have no idea what you're trying to do.
Your posts are confusing, this part of Plesk is not

It's fairly simple.

I have domain.local (domain), sub.domain.com is an alias for domain.local. From sub.domain.com (which has a valid letsencrypt certificate) I am trying to connect to an external FTP with TLS. I can't because Plesk apparently uses the wrong CA certificate. Hopefully that answers your question...

 

[mr-wolf]

It's fairly simple.

I have domain.local (domain), sub.domain.com is an alias for domain.local. From sub.domain.com (which has a valid letsencrypt certificate) I am trying to connect to an external FTP with TLS. I can't because Plesk apparently uses the wrong CA certificate. Hopefully that answers your question...

You are obfuscating the real domain you're using which is your good right (I hate "domain.com" as it says nothing about your usage)

If you're using local DNS or a host file to trick your client to go to a .local address then that's irrelevant as it is only used for resolving and the server will be unaware of that. You would not need to mention that (confusing and distracting).

I don't understand however why a .local comes into this. A letsencrypt certificate needs a webserver that is publicly available on that domain so why not use that domain...

Either you have a poor choice when obfuscating the real domains you're using, you totally don't understand DNS and SSL or you're using some brilliant trick I don't understand...

The latter becomes less likely knowing you can't get it to work.


[EDIT]
I read your first post a bit better (started reading half way) and understand your situation a bit better. What I wrote in this post is still correct.

Resolving the dns name is done before connecting and how the client obtained it is not being used after that.
Does it point to localhost or to your WAN IP?

If it's the WAN IP and the same IP as on Google's DNS (8.8.8.8) then it should not have been mentioned here.

 

[Sysop]

You are obfuscating the real domain you're using which is your good right (I hate "domain.com" as it says nothing about your usage)

Yes, it's obfuscation and I'll agree it's a terrible method, although is there a globally excepted "filler" domain name other than example.com?

If you're using local DNS or a host file to trick your client to go to a .local address then that's irrelevant as it is only used for resolving and the server will be unaware of that. You would not need to mention that (confusing and distracting).

It's definitely not a host file trick.

I don't understand however why a .local comes into this. A letsencrypt certificate needs a webserver that is publicly available on that domain so why not use that domain...

Either you have a poor choice when obfuscating the real domains you're using, you totally don't understand DNS and SSL or you're using some brilliant trick I don't understand...

The latter becomes less likely knowing you can't get it to work.

I'm an advocate of sharing knowledge — this is what I'm actually doing:

This procedure works for Plesk Onyx Version 17.5.3+ and Red Hat/Centos 7.x ( It should even work for Windows servers, although untested ).

1. Login to the Plesk control panel and create a new subscription with the following values:

- Add Subscription
- Domain name: onyx.local
- Shared IP
- Username: onyx_local

2. (Optional) Open the control panel for onyx.local and create a database and database user with the following values (this can be used as a central db for multiple domain aliases):

- Database name: onyx_local
- Username: onyx_local

3. Create a domain alias for one of your existing domains such as onyx.example.com to onyx.local.

If you do not have a wildcard DNS entry then you will have to create an A record for the onyx.example.com alias you just created.

Additional/Optional:

- Set up additional domain aliases to onyx.local for each domain that you want to associate with it.

Advanced Additional/Optional:

- For any domains that do not have a wildcard entry in their DNS you will need to create an onyx A type record.
- It's possible to remove the onyx.example.com alias that you created in step 3 if desired.
- This setup is appropriate for servers that have numerous domains or regularly add/remove domains.

Within this setup I would like to mount external FTP sites with TLS/SSL from the alias domain(s) to the onyx.local subscription. The problem is either (1) Plesk is not associating the correct CA Certificate with the domain aliases, or (2) some other configuration problem caused by having to manually associate ssl certs with each alias perhaps. Regardless of what you think I know about DNS there are specific reasons I take this approach; I have lots of users, web apps, and domain names going into this "local" subscription, and while it's unconventional it works remarkably well interconnecting all of these things together.

 

[mr-wolf]

I have lots of users, web apps, and domain names going into this "local" subscription, and while it's unconventional it works remarkably well interconnecting all of these things together.

I believe you're posting here because it's not working....

I suspect the ".local solution" will turn out to be the cause of your problem.

I still don't understand what you're trying to achieve. The whole obfuscation thing makes it unclear.

If you're obfuscating you should not use example.com or domain.com, but things like myclient.com or mycompany.com.

Proftpd provides the certificate that is set server-wide. By default it's a self-signed certificate.

The client asks for a certain host-name (if it supports SNI), but will not get that because proftpd is not configured to use SNI.
It will provide the certificate of the server ALWAYS.
If your client expects a certificate matching the hostname it provided it may raise a problem (hostname does not match CN's in certificate).
In that case the connection will not work.
To make it work you should tell it not to check for a match.

As it's still not clear to me what you're actually providing where it may not be the answer you're looking for.

To be helpful I need to consider things you may not know. Because I don't know you this is almost impossible. Maybe the key is in this post maybe not. It could even well be that there is something happening that I don't know.

 

[mr-wolf]

Within this setup I would like to mount external FTP sites with TLS/SSL from the alias domain(s) to the onyx.local subscription. The problem is either (1) Plesk is not associating the correct CA Certificate with the domain aliases

It never did!!
FTP, SMTP, POP and IMAP are all using 1 certificate.
The Plesk interface on port 8443 is also configured to use 1 certificate.
You can set this certificate server-wide in Plesk settings.

For this you need SNI (Server Name Indication) and this is a reasonably new feature that's only supported in HTTP. It seems that the next version of Plesk (17.8) will have SNI-support for other servers than http (ftp, pop, imap, smtp).
Although those services themselves (Postfix, ProFTP and Dovecot) do support this, it is not configured that way.
On top of that you can't rely on the clients to support it.
Although all HTTP-browsers support SNI, it's a totally different ball game for the other clients.
Your PHP ftp-connect may not even support it.
So waiting for 17.8.3 may not be enough for you.

I totally avoid the reliance on SNI by providing 2 public hostnames for each client. These hostnames will match the wildcard domain I'm using on all my servers.

I tell client1 with the domain client1.com to connect his mail clients with

client1-com.wolf.com

If he wants to connect to the web/ftp server he needs to connect to

www-client1-com.wolf.com

For each client I have these 2 cnames that point to respectively mail.client1.com and client1.com.

client2.org would have the 2 other wolf.com cnames

client2-org.wolf.com IN CNAME mail.client2.org
www-client2-org.wolf.com IN CNAME client2.org

client2.org may point to another Plesk server of mine than client1.com.

To connect I tell client2 to connect to

• Plesk => https://www-client2-org.wolf.com:8443
• FTPS => ftps://www-client2-org.wolf.com
• SMTPS => client2-org.wolf.com port 587
• IMAPS => client2-org.wolf.com port 143, 993

I have an hourly cronjob that creates those cnames in wolf.com (typically after adding it to the DNS server). I have a separate Plesk for DNS on which wolf.com resides. You would have more difficulty to create those cnames automatically if you have more than 1 DNS (most people use the server on which the mail/website is running as authorative DNS for that domain). In that case you need to create the records cnames manually.

Not using the DNS of the different Plesk servers has more advantages than disadvantages in my scenario.

• I know I can always go to that server to get/edit all the DNS-info.
• I can manage the DNS of all my clients using scripts (think of the rotating DKIM-keys).
• Moving a site to another server of mine doesn't require a change at the registrar.
• DNS changes can't be done by clients (in my scenario an advantage, I can imagine it to be a disadvantage for others).
• The webservers are all on the same infrastructure. By having the primary server in another infrastructure I'm following best-practice.

Those 2 cnames will therefore always resolve to the appropriate AND match the wildcard certificate *.wolf.com I have defined there.

As icing on the cake I was able to expand on this by writing my own autoprovisioning that doesn't need an Nginx entry for each host but is capable to do that with a single server-wide entry.

Microsoft is doing something similar with their on-microsoft.com domain.

I even provide weekly rotating DKIM keys using my own domain as intermediate (just like Microsoft is doing).
I'm not using Plesk's DKIM solution.


[EDIT]

Are you aware that unlike the http-server (Nginx/Apache) that the ProFTP-server in its standard configuration?

• ...Is not aware of the hostname provided by the FTP-client
• ...It will always provide the certificate configured server-wide in Plesk. It may therefore not match with the hostname the FTP-client is supplying
• ...It is choosing the workspace based on the login, not on the hostname.

If the PHP FTP-connection is to itself (same server) why don't you do a plain FTP-connection to localhost? As you're obfuscating everything into meaningless hostnames I still can't get a grip on your specific scenario.