Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/232#discussion_r53211145
--- Diff:
nifi-nar-bundles/nifi-amqp-bundle/nifi-amqp-processors/src/main/java/org/apache/nifi/amqp/processors/AbstractAMQPProcessor.java
---
@@ -84,6 +89,72 @@
.allowableValues("0.9.1")
.defaultValue("0.9.1")
.build();
+ public static final PropertyDescriptor USE_SSL_PROTOCOL = new
PropertyDescriptor.Builder()
+ .name("Use SSL protocol")
+ .description("Indicates whether or not SSL protocol should be
used")
+ .allowableValues("true", "false")
+ .defaultValue("false")
+ .required(true)
+ .build();
+ public static final PropertyDescriptor VALIDATE_CERTIFICATES = new
PropertyDescriptor.Builder()
--- End diff --
Thanks @pvillard31 . I read the linked documentation, and what they are
describing is if the trust chain (the cryptographic link between the presented
certificate identifying a resource and a trusted certificate of a known entity
proving the relationship) should be verified, specifically for _client
certificates_.
> When a web browser connects to an HTTPS web server, the server presents
its public certificate, the web browser attempts to establish a chain of trust
between the root certificates the browser is aware of and the server's
certificate, and all being well, an encrypted communication channel is
established. Although not used normally by web browsers and web servers, SSL
allows the server to ask the client to present a certificate. In this way the
server can verify that the client is who they say they are.
> This policy of whether or not the server asks for a certificate from the
client, and whether or not they demand that they are able to trust the
certificate, is what the verify and fail_if_no_peer_cert arguments control.
Through the {fail_if_no_peer_cert,false} option, we state that we're prepared
to accept clients which don't have a certificate to send us, but through the
{verify,verify_peer} option, we state that if the client does send us a
certificate, we must be able to establish a chain of trust to it.
In this case, I am comfortable with not requiring the client to present a
certificate, but I don't think we should provide the option to present an
invalid/malformed certificate and successfully connect. If a client certificate
is presented, we should require it to validate successfully against a
certificate within the provided truststore.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
