As I have content marketers working regularly on Stage, and using Deploy regularly to push edits to Live, I upgraded Deploy to the latest greatest on my Dev environment for testing, and was trying to test deploying from the new version on Dev to to prior on Stage. Again, Dev is on 7.x-2.0-beta1 while Stage is still on 7.x-2.0-alpha3.

I get the following error on Dev with failure in deployment:

DeployAuthenticationException: Authentication error: 0 Error opening socket ssl://stage.myserver.com:443 in DeployAuthenticatorSession->deploy() (line 76 of /.../sites/all/modules/deploy/plugins/DeployAuthenticatorSession.inc).

I noticed that in DeployAuthenticatorSession there is this new bit of code in the Deploy function, which doesn't exist in alpha3, for fetching the context for the HTTP request (http://cgit.drupalcode.org/deploy/commit/?id=b68ce12).

Any pointers on this new bit, how it relates to the Deploy process, and whether the error is simply a mishmosh in Deploy module versions? I can't find a reference for it anywhere else.

Thanks!

Comments

capogeannis created an issue. See original summary.

capogeannis’s picture

Went ahead and just upgraded the module in both environments - same error. Is there some new permission setting required on the server end for this beta1 version to not fail with that mentioned "Error opening socket ssl..." error?

capogeannis’s picture

Priority: Normal » Major
capogeannis’s picture

Title: beta1 to alpha3 failing on deploy/fetchContext » Upgrade to beta1 causes socket ssl error
capogeannis’s picture

A bit more detail...

Turning on debugging in Deploy shows this error thrown:

Authentication response: stdClass Object
(
[code] => 0
[error] => Error opening socket ssl://www.website.com:443
)

I can see that the code change in the Deploy function now creates a context via stream_context_create explicitly setting ‘ssl’ as the protocol, which in my case throws the socket error during the communication attempt.

verify_ssl = variable_get('deploy_verify_ssl', TRUE);
$context_options = array(
'ssl' => array(
'verify_peer' => $verify_ssl,
'verify_peer_name' => $verify_ssl,
'allow_self_signed' => !$verify_ssl,
),
);
$context = stream_context_create($context_options);

So in the end, the only difference is the inclusion of that ssl context into the options array:

$options = array(
'method' => 'POST',
'headers' => array('Content-Type' => 'application/json'),
'data' => drupal_json_encode(array(
'username' => $this->config['username'],
'password' => $this->config['password'],
)),
'context' => $context,
);

I THINK the issue then is server side on the openssl settings ~ socket not opening because the SSL certification couldn’t be verified. Similar to:
https://www.drupal.org/node/1879970
http://tocacar.com/tag/sockets/
...but that's about all I've got ~ reaching.

Any info greatly appreciated if anyone has a pointer in this regard. Thanks.

Shiraz Dindar’s picture

same issue here with beta1. Did you end up finding a solution?

capogeannis’s picture

Sorry, was away on vacation. Nope, have not as of yet found a solution besides potentially commenting out the ssl context inclusions in the module - though I don't k now what the trickle down effect is on that, don't want to hack the module, and know it was included for a good reason.

I'd really like to know what I need to change on my architecture end for this to work. In the meantime, I have to hold off on upgrading the module.

dixon_’s picture

Status: Active » Postponed (maintainer needs more info)

What PHP version are you guys using? And are you using valid and signed SSL certificates or not?

I recall running into this issue as well during a recent PHP upgrade. And if I recall correctly a recent version of PHP 5.6 (I think) started being picky about valid SSL certificates. This could be the issue.

capogeannis’s picture

Good point. I'll check with Op's here. Our architecture internally is pretty locked down - working with handcuffs on here. : )

I know they did do a PHP upgrade recently of these internal servers to PHP 5.4.42.

Not noticing any issues with the SSL, but I'll find out and report back.

Many thanks.

capogeannis’s picture

Looks like our certs for the internal servers we develop on are self-signed, or something to that effect. Will be working with our guy here around mid January to look into that. Good chance that's it then? I'll update here after that.

bzaher’s picture

I ran into the same issue as well, and I can confirm that the deploy_verify_ssl variable is involved, shown in the second snippet in #5. Using the drush command drush vset deploy_verify_ssl 0 solves the issue.

I am using a self-signed certificate with PHP 5.5.9.

Looking at 'allow_self_signed' => !$verify_ssl,, this code appears to be doing what it was intended to do. Setting deploy_verify_ssl to true prevents deployments using self-signed certs, and setting it to false allows them. Maybe there ought to be a UI setting to enable this?

capogeannis’s picture

Thanks, bzaher. #11 variable settings fixes it for me ~ or rather than saying "fix", sets up my particular environment properly for this latest release. Would be good to include that in the docs somewhere.

capogeannis’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Issue turned out to be self-signed certs not jiving with the new deploy_verify_ssl variable defaulting to 1. Setting to 0 in DB manually in variables table or via drush noted in #11 properly sets up self-signed certs environments for this latest version.

Shiraz Dindar’s picture

Thanks for your work on this, folks. Setting that var to 0 worked for me too.