Hi Viktor
Thanks for this confirmation. I think the correct approach would be to use
our internal CA.
On Tue, Mar 7, 2017 at 7:16 PM, Viktor Dukhovni <openssl-us...@dukhovni.org>
wrote:
>
> > On Mar 7, 2017, at 2:21 AM, Traiano Welcome <trai...@gmail.com> wrote:
> >
> > I have a private DNS zone hosted on AWS route 53, only resolvable from
> > within some specific VPCs.
> > It appears some applications require an SSL certificate associated with
> > the private DNS zone, and this SSL certificate should come from a
> trusted,
> > external certificate provider (cannot be self-signed).
>
> The "trusted external" CA that issues the not-self-signed end-entity cert
> can almost certainly (with appropriate configuration of the client app)
> be a private CA that you create and provide to the SSL clients.
>
> In which case the question below is moot.
>
> > My questions are:
> >
> > a) Is this a known use-case? i.e private dns zones requiring
> non-self-signed
> > certificates?
>
> I usually use private CA certs for use on non-public networks.
>
> > b) Since the DNS zone is not resolvable on the public internet,
> > how would the certificate validation process occur for applications
> > communicating with systems in the private zone ?
>
> There is some prior history of public CAs issuing certificates for
> private namespaces, but IIRC this practice is discouraged and going
> away.
>
> > c) Do SSL certificate providers issue trusted SSL certificates for
> private DNS zones?
>
> It is not really possible for them to know that the names in question
> are used in another "private" deployment elsewhere.
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
