[
https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17264141#comment-17264141
]
Gordon Sim commented on DISPATCH-1903:
--------------------------------------
Agree with Robbie that it *might* be simpler overall to have e.g. caCertString,
certString and privateKeyString, with pem encoded strings as values and never
bother trying to write them out. Typical certs/keys are not that long, 2k or
so. I wouldn't recommend this as an approach for the config file, but over the
management protocol that would work fine.
Alternatively you could have e.g caCertRef, certRef, privateKeyRef and then
have a new 'named blob' entity that these refer to. The named blob would be
created/deleted using management and held in memory.
> Remote upload of certificate files for new TLS configurations
> -------------------------------------------------------------
>
> Key: DISPATCH-1903
> URL: https://issues.apache.org/jira/browse/DISPATCH-1903
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Container
> Reporter: Ted Ross
> Assignee: Ted Ross
> Priority: Major
> Fix For: 1.15.0
>
>
> Currently, when using the management protocol to create new SSL-profiles,
> those profiles must access certificate files that are already placed in the
> file system. In other words, in order to create an SSL-profile on a running
> router, files must first be placed on the file system in a location
> accessible by the router. This may be problematic in cases where the router
> is remote from the managing agent, or when containerization limits access to
> the router's underlying file system.
> This new feature allows a managing agent to remotely inject files into a
> running router to be stored in temporary file storage. These files are
> usable in sslProfile management entities (by specifying the files without an
> absolute path). The temporary files are removed from the file system on
> router shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
