►
From YouTube: OpenShift Demo Part 13: Using SSL
Description
In this video, Veer Muchandi explains how to use SSL with OpenShift and the different options that you, the developer, have available.
In the blog post https://blog.openshift.com/openshift-demo-part-13-using-ssl/ you can find some of the commands Veer used during this demo.
NOTE: For the latest information on OpenShift 3, please visit https://enterprise.openshift.com or subscribe to the OpenShift Blog (https://blog.openshift.com).
A
Hello:
everyone,
this
video
is
about
using
ssl
with
openshift.
There
are
a
couple
of
different
options
that
OpenShift
provides
for
using
ssl
and
we
will
look
at
those
different
options.
To
begin
with,
I
have
deployed
a
kitchen
sink
java
application.
It's
it's
already
running
and
it
is
it's
not
using
ssl.
A
A
It
says
no
service
available,
but
with
HTTP
it
works.
Now,
let's
see
what
kind
of
changes
we
need
to
make
to
this
application
to
enable
SSL.
So
we
have
an
application
that
has
no
SSL
and
the
way
in
which
this
is
set
up,
you
know
shift
is
there
are
a
bunch
of
parts,
for
example,
for
your
application
running
and
there
is
a
route
that
is
configured
inside
the
router
when,
as
a
user,
you
are
trying
to
reach
this
application
with
the
HTTP
based
URL.
A
A
The
user
asks
for
the
app
using
HTTP
based
URL,
using
SSL
between
the
browser,
the
client
and
the
router.
The
traffic
is
encrypted
between
the
browser
and
the
router,
and
the
SSL
terminates
at
the
router
and
from
there
on
the
traffic
between
the
router
and
your
application,
which
is
within
the
scope
of
your
environment,
could
be
unencrypted.
So,
in
order
to
enable
edge
termination,
we
have
to
make
a
small
change
to
this
route.
So
let's
have
a
look
at
the
route
and
switch
the
project.
A
A
I'll
save
this
at
this
point,
as
a
cell
with
work
with
edge
termination
and
TLS
termination
occurs
at
the
router
prior
to
proxying
traffic
to
its
destination,
the
TLS
certificates
are
served
by
the
front
end
of
the
router,
so
they
must
be
configured
into
the
route
if
you
have
TLS
certificates
to
be
configured
otherwise,
in
our
case,
since
we
did
not
configure
any
certificates,
TLS
default
router
certificate
would
be
used
for
termination.
So,
if
I
test
the
application
now
with
HTTPS,
this
application
is
running
earlier.
A
When
we
tried
HTTP,
we
got
a
service
not
available,
but
now
it
is
running
with
HTTPS.
That
means
the
TLS
edge
termination
is
working.
Now
we
will
see
how
to
configure
a
certificate
into
this
route,
so
first
I'll
for
for
this
purpose,
I'll
use
a
a
self-signed
certificate.
I'll
create
a
self-signed
certificate
using
the
key,
so
let's
say
I'm
using
key
tool
to
generate
a
certificate.
It's
a
self
signed
certificate.
It
will
generate
a
key
store,
JK's
file.
A
It
has
a
password
super
secret
and
all
that
stuff,
so
I
keyed
in
all
the
values
it
asked
for
and
now
it
has
generated
a
keystore
file
now
in
order
to
use
the
certificate
and
a
private
key
that
that
got
generated
along
with
this,
there
is
a
little
curve
on
a
Mac
I
have
to
convert
this
into
pkcs12
format.
Thanks
to
my
colleague
rom
who
has
provided
this
information,
so
all
I
did
is
I
used
the
key
tool
to
convert
this
key
format
from
jks
format
to
the
peak
pkcs12
format.
A
A
Let
me
first
copy
the
private
key
and
certificate
now
I'll
edit
the
route
again
to
add
this
private
key
and
certificate
to
the
route
for
each
termination
right
below,
where
we
added
the
termination
as
edge
I,
will
add
the
certificate
and
key
sections
there.
You
have
pasted
the
value
of
key
and
also
place
my
certificate
here
and
I
paste
with
the
value
of
certificate.
The
alignment
is
important
in
a
ml
file.
A
I'll
say
this
route
with
these
changes,
and
now
my
route
is
ready
with
my
certificates
as
well,
so
that
is
how
each
termination
can
be
used
with
certificates.
Now,
let's
talk
about
the
next
type
of
termination
model
which
is
passed
through
in
this
case
the
encrypted
traffic
with
pass
through
termination.
The
the
traffic
is
sent
straight
to
the
destination
without
the
router
providing
any
TLS
termination.
Therefore,
no
key
or
certificate
is
required
at
the
router
level,
so
you
would
not
configure
anything
into
the
route.
A
On
the
other
hand,
the
destination
power
would
be
responsible
for
serving
certificates
for
the
traffic
at
the
endpoint,
so
we
would
have
to
some
way
provide
the
certificate
that
we
created
earlier
to
the
destination
and
we'll
go
through
how
to
do
that.
So,
for
this
purpose,
I
created
a
new
project,
I
called
it
pass
through.
Let
me
switch
over
to
that
project.
Now.
If
you
remember,
we
used
this
command
the
key
tool
command
to
to
create
the
the
key
store
earlier.
A
We
will
be
using
that
key
store,
I'm,
not
running
this
command
now,
but
we
I
just
wanted
to
show
you
what
we
did
before.
We
created
a
key
store
by
using
this
command
and
we
had
a
password
of
super
secret
right.
We
will
be
using
this
password
as
well.
Now
we
have
a
key
store
here
that
we
created
earlier,
so
we
will
use
this
key
store
to
create
what
we
call
a
secret
in
this
project.
Secrets
are
storage
for
sensitive
information
such
as
keys,
passwords
and
certificates,
and
these
are
accessible
by
the
intended
pods.
A
So
remember
what
I
said
before
we
have:
the
traffic
reaches
all
the
way
to
the
pod
and
pod
is
responsible
for
serving
certificates,
and
the
secrets
are
away
in
which
we
are
making
the
certificates
available
to
the
par
so
that
it
can
serve
those
certificates
right.
So
all
I'll
do
is
create
a
secret
now
by
using
this
command
I'm
saying
OC
secrets
and
I'm
creating
a
new
secret.
The
name
of
the
secret
is
EAP
AB
secret
and
I'm.
Using
this
key
store,
JISC
jks
file,
which
has
my
self
signed
certificate
right,
I'm
mounting
that
certificate.
A
A
This
is
the
one
that
just
got
created
and
if
I
look
at
what
the
secret
looks
like
OC
get
secret
as
a
JSON
I
see
that
this
secret
has
the
metadata,
and
the
data
of
this
is
coming
from
the
keystore
JK's
file,
and
this
is
all
the
content
easy
now.
There
is
one
more
step
to
use
the
secret.
We
need
a
service
account
and
the
service
account
will
allow
your
application
to
use
that
secret
in
order
to
enable
that
SSL
traffic.
A
So
let's
look
at
what
service
accounts
we
have
right
now,
I
can
say
service
account
or
simply
s.a
right
now
there
is
a
service
account
for
builder
service
account,
which
is
default
for
the
project
and
a
service
account
for
deploy.
We
will
create
another
service
account
I
am
echoing
adjacent
here
to
create
based
on
this
file
that
that
there
is
a
code
here.
I
am
trying
to
create
a
service
account
and
I
am
naming
the
service
account
as
EAP
service
account
and
I
am
also
saying
that
this
service
account
would
be
using
this.
A
We
are
ready
to
launch
a
HTTP
based
application,
and
that
part
is
easy,
because
we
do
have
a
template
for
creating
an
HTTP
based
application,
so
I
am
creating
a
new
application
and
I
will
create
an
application
based
on
a
template
and
for
this
I
am
using
a
EAP
HTTP
SDI
template
STI
stands
for
source
to
image.
So
if
I
change
a
few
parameters,
I'll
call
this
secure
application
right
and
then
let
it
pick
up.
It's
the
default.
Hostname
I,
don't
want
to
change
that.
A
I
will
just
run
the
default
kitchen-sink
application
that
this
template
deploys.
I
don't
want
to
change
it,
but
what
I'm
interested
in
here
is
Lucas.
Look
at
this
EAP
HTTP
secret
I
want
to
use
the
EAP
app
secret
right
this.
This
is
the
one
that
we
created.
The
default
name
is
given
as
aap
app
secret.
That's
the
reason
why
I
mounted
it
that
way.
If
you
wanted
to
create
a
secret
with
a
different
name,
you
could
actually
I
could
have
called
this
my
secret
and
then
I
could
have
changed
the
name.
A
Here
I
am
also
saying
that
the
key
store
files
name
is
key
stored
or
JK's
right.
If
the,
if
the
key
store
name
was
different,
then
we
could
have
changed
this
name
now.
The
HTTP
name,
it's
if
I
called
the
alias
as
self-signed
I'll
call
it
the
same
here
and
the
password
remember.
When
we
created
the
key
store,
we
gave
a
pass
for
the
super
secret
and
I'm
using
the
same
thing
here
now:
I
just
press
on
this
create
button.
A
Now
this
will
go
ahead
and
deploy
the
default
kitchen
sink
application
that
comes
with
this
template
and,
as
you
can
see,
there
are
two
routes
that
got
created.
One
is
the
regular
HTTP
route,
which
is
not
secure
right
and
the
other
one
is
the
HTTPS
SSL
based
route,
so
two
routes
for
the
same
application
got
created
now
in
a
in
a
couple
of
minutes.
This
application
will
that
there
will
be
a
build
process
that
will
get
started
and
once
the
build
is
complete,
the
application
will
get
deployed.
A
This
will
take
a
couple
of
minutes,
so
I
will
pause
and
I
will
come
back
once
the
once
the
build
and
deployment
is
complete.
Now
the
application
is
built
and
deployed,
I
will
scroll
over
to
the
HTTP
spaced
route,
and
let
me
open
that
part
of
the
application,
so
the
security
warning-
and
here
is
the
running
application
using
HTTPS.
Now,
in
this
case,
this
application
is
using
pass-through
termination.
If
I
say
OC
get
routes.
A
I
see
these
two
different
routes:
one
is
the
secure
route
right,
this
HTTP
route
and
this
secure
route
is
set
with
a
TLS
termination
of
pass-through.
Let
me
also
show
it
as
Z
ammo
so
that
you
can
compare
with
what
we
have
seen
before
here.
The
termination
is
set
as
pass-through
now
who
said
this
pass-through
termination,
it's
it's
coming
from
the
template.
When
you
deploy
that
particular
HTTP
STI
template
the
termination
is
set
to
pass
through
when
the
route
got
created
and
all
we
did
was
we.
A
We
set
up
a
secret
and
we
we
enable
secret
wire,
the
service
account.
Now
the
pod
can
serve
the
certificates
by
using
the
secret
now.
The
third
kind
of
termination
method
that
openshift
allows
is
called
a
ring.
Encrypts
termination,
in
this
case
green
encryption,
is
a
variation
of
the
edge
termination
where
the
router
terminates
TLS
with
a
certificate
and
then
re
encrypts
its
connection
to
the
endpoint,
which
may
have
a
different
certificate.
So
the
although
whole
paths
on
both
sides
of
the
router
are
encrypted.
A
The
rien
Krypton
to
the
to
the
endpoint
happens
with
a
different
certificate.
Although
I
don't
have
an
example
to
show
how
it
works,
the
architecture
guide
talks
about
how
it
can
be
accomplished.
So,
just
like
in
case
of
H
termination,
you
would
have
TLS
and
the
termination
set
to
re-encrypt.
In
this
case,
you
will
provide
two
different
kinds
of
things.
A
One
is
the
key
that
is
used
just
like
in
its
share
and
termination,
the
private
key
the
certificate,
and
if
you
have
a
CA
certificate,
you
provide
that
as
well
and
for
rien
Krypton
you'll
provide
a
destination
certificate
which
will
be
used
for
encryption
behind
the
router.
That
means
between
the
router
and
your
pod.
I
hope
you
enjoyed
this
video
thanks
a
lot
for
watching.