Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This allows old ssl_multicert.config to still function on reload #1488

Closed
wants to merge 1 commit into from

Conversation

zwoop
Copy link
Contributor

@zwoop zwoop commented Feb 24, 2017

The problem is that if a certificate fails to load, for whatever reason that might be, ATS still switches the configuration, leaving the server in a crippled state. This patch fixes this, to the normal behavior of ATS retaining the old configurations if the new fails to load.

@zwoop zwoop added this to the 7.1.0 milestone Feb 24, 2017
@zwoop zwoop self-assigned this Feb 24, 2017
@atsci
Copy link

atsci commented Feb 24, 2017

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/freebsd-github/1613/ for details.

@atsci
Copy link

atsci commented Feb 24, 2017

Intel CC build successful! See https://ci.trafficserver.apache.org/job/icc-github/46/ for details.

@atsci
Copy link

atsci commented Feb 24, 2017

Linux build successful! See https://ci.trafficserver.apache.org/job/linux-github/1508/ for details.

if (ssl_store_ssl_context(params, lookup, &sslMultiCertSettings) == nullptr) {
Error("failed to load SSL server contexts");
return false;
}
} else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused why this fixes anything. I don't see any callers checking the return value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeh, it's not used, but the point is that we stop parsing the configuration at this point, which leaves lookup->is_valid == false (correctly). I believe in the old version, the status of the lookup is the status of the last certificate in the configuration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be fine adding additional actionable checks here if you like, I'm just not familiar with most of this code.

@atsci
Copy link

atsci commented Feb 24, 2017

clang-analyzer build successful! See https://ci.trafficserver.apache.org/job/clang-analyzer-github/178/ for details.

@zwoop
Copy link
Contributor Author

zwoop commented Feb 24, 2017

I see now, there's a new configuration, proxy.config.ssl.server.multicert.exit_on_load_fail, which would exit on load errors. Surprised that this is not the default to "1" though.

However, the fix above would retain (what I think is) correct behavior on reloads, and if proxy.config.ssl.server.multicert.exit_on_load_fail is off (0), you'd still be able to load the initially broken configuration.

Why anyone wants a broken configuration is beyond me, but I'm ok with this, but think it should be changed to "1" for v8.0.0.

@zwoop
Copy link
Contributor Author

zwoop commented Feb 24, 2017

I'm gonna close this PR for now, I think this code could be cleaned up, but setting proxy.config.ssl.server.multicert.exit_on_load_fail=1 seems to behave more reasonable than the defaults.

@zwoop zwoop closed this Feb 24, 2017
@zwoop zwoop deleted the FixSSLLoadFailure branch February 24, 2017 23:38
@zwoop zwoop modified the milestone: 7.1.0 May 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants