[
https://issues.apache.org/jira/browse/TS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14315219#comment-14315219
]
James Peach commented on TS-3329:
---------------------------------
It might be inconsistent, but I think that this is different. Failing to serve
a SSL hostname has different effects than a subset of remap rules being missing.
I think that I'd be OK with a failure in SSL cert loading causing the subsystem
reload to fail since that would be consistent with handling of other
subsystems. I am not ok with the current patch.
Note that there's a big grey area here. We ought to be tolerant of self-signed
certificates, but should we be tolerant (or check for) with certificates that
don't verify?
> ATS shouldn't start if SSL is configured and certificate can't be loaded
> ------------------------------------------------------------------------
>
> Key: TS-3329
> URL: https://issues.apache.org/jira/browse/TS-3329
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
> Reporter: kang li
> Assignee: kang li
> Labels: review
> Fix For: 5.3.0
>
> Attachments: patch.diff
>
>
> requirement by [~dcarlin]:
> {quote}
> It seems ATS will start up even if the certificate file isn't present.
> ATS settings in records.config:
> CONFIG proxy.config.ssl.server.cert_chain.filename STRING digicert.pem
> CONFIG proxy.config.ssl.server.cert.path STRING conf/yts/ssl
> ATS settings in ssl_multicert.config:
> dest_ip=* ssl_cert_name=ycpi_ssl_cert.pem
> What happened was that this volume /home/y/conf/yts/ssl wasn't mounted - so
> the
> SSL cert and chain cert were inaccessible. ATS started anyways just
> returning
> errors on 443. Healthchecks were served on port 80 via HTTP, so it appeared
> to that the site was OK.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
