U.S. patent application number 15/055393 was filed with the patent office on 2016-09-08 for credentials management in large scale virtual private network deployment.
The applicant listed for this patent is Palo Alto Networks, Inc.. Invention is credited to Nicholas Campagna, Yueh-Zen Chen, Monty Sher Gill, Martin Walter.
Application Number | 20160261563 15/055393 |
Document ID | / |
Family ID | 52473145 |
Filed Date | 2016-09-08 |
United States Patent
Application |
20160261563 |
Kind Code |
A1 |
Walter; Martin ; et
al. |
September 8, 2016 |
CREDENTIALS MANAGEMENT IN LARGE SCALE VIRTUAL PRIVATE NETWORK
DEPLOYMENT
Abstract
Techniques for credentials management in large scale virtual
private network (VPN) deployment are disclosed. In some
embodiments, credentials management in large scale VPN deployment
includes generating a public/private key pair and a certificate
signing request at a satellite device; automatically communicating
the certificate signing request to a portal over a public,
untrusted network to authenticate the satellite device using a
serial number associated with the satellite device, in which the
certificate signing request and the serial number are verified by
the portal; and receiving a certificate from the portal for using
to establish VPN connections and configuration information for the
satellite device, in which the certificate includes a credential
signed by a trusted certificate authority, and the configuration
information includes gateway configuration information identifying
a plurality of gateways to which the satellite device is configured
to connect using VPN connections.
Inventors: |
Walter; Martin; (Livermore,
CA) ; Campagna; Nicholas; (San Jose, CA) ;
Chen; Yueh-Zen; (San Jose, CA) ; Gill; Monty
Sher; (San Jose, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Palo Alto Networks, Inc. |
Santa Clara |
CA |
US |
|
|
Family ID: |
52473145 |
Appl. No.: |
15/055393 |
Filed: |
February 26, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14596062 |
Jan 13, 2015 |
9306911 |
|
|
15055393 |
|
|
|
|
13754796 |
Jan 30, 2013 |
8966260 |
|
|
14596062 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 63/101 20130101;
H04L 63/08 20130101; H04L 63/029 20130101; H04L 63/062 20130101;
H04L 63/0876 20130101; H04L 63/0245 20130101; H04L 63/108 20130101;
H04L 63/0823 20130101; H04L 63/0272 20130101; H04L 63/0263
20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
Claims
1. (canceled)
2. A method, comprising: receiving a certificate signing request
(CSR) at a portal sent from a security device over a public network
to authenticate the security device using a serial number
associated with the security device; verifying the CSR and the
serial number; and sending a certificate from the portal to the
security device for using to establish virtual private network
(VPN) connections and configuration information for the security
device, wherein the certificate includes a credential signed by the
portal as a trusted certificate authority, and wherein the
configuration information includes gateway configuration
information identifying a plurality of gateways to which the
security device is configured to connect using VPN connections.
3. The method of claim 2, wherein the security device communicates
with the portal at a portal address to register the security device
with the portal by executing a boot-up process or script, and
wherein the portal was previously configured to recognize the
serial number of the security device for provisioning the security
device.
4. The method of claim 2, wherein the CSR sent to the portal over
the public network to authenticate the security device is verified
by the portal using Public Key Infrastructure (PKI), and wherein
the portal is a certificate authority.
5. The method of claim 2, further comprising: storing the serial
number and a hostname associated with the security device in a
satellite list maintained at the portal.
6. The method of claim 2, further comprising: sending a list of
trusted Certificate Authorities (CAs) from the portal to the
security device for verifying certificates from the portal and/or
each of the plurality of gateways.
7. The method of claim 2, further comprising: receive a request at
the portal from one of the plurality of gateways to verify the
certificate for the security device, wherein the portal determines
whether the certificate is still valid and has not been
revoked.
8. The method of claim 2, wherein de-authorization of the security
device using the portal comprises: removing the serial number
associated with the security device from a portal configuration
stored at the portal, and wherein the certificate for the security
device is automatically revoked.
9. The method of claim 2, further comprising: removing a serial
number associated with a gateway from a gateway configuration
stored at the portal, wherein the gateway can no longer renew its
certificate and/or does not automatically receive a new short term
life (STL) certificate from the portal.
10. The method of claim 2, further comprising: removing a serial
number associated with a first gateway from a gateway configuration
stored at the portal; and receiving a request from a second gateway
or the security device for a revocation list at the portal.
11. The method of claim 2, further comprising: determining whether
the certificate has expired at the portal; and in the event that
the certificate has expired, the serial number associated with the
security device is removed from an Online Certificate Status
Protocol (OCSP) list stored at the portal.
12. The method of claim 2, wherein the certificate for the security
device is a short term life (STL) certificate, and further
comprising: executing an auto renewal process at the portal,
wherein the portal automatically renews the STL certificate for the
security device.
13. The method of claim 2, further comprising: executing an auto
renewal process at the portal, wherein the portal periodically
sends new or updated certificates for the security device and for
each of the plurality of gateways and updated gateway configuration
information.
14. A system, comprising: a processor of a security device
configured to: generate a public/private key pair and a certificate
signing request (CSR); send the CSR to a portal over a public
network to authenticate the security device using a serial number
associated with the security device, and wherein the CSR and the
serial number are verified by the portal; receive a certificate
from the portal for using to establish virtual private network
(VPN) connections and configuration information for the security
device, wherein the certificate includes a credential signed by the
portal as a trusted certificate authority, and wherein the
configuration information includes gateway configuration
information identifying a plurality of gateways to which the
security device is configured to connect using VPN connections; and
attempt to connect the security device to each of the plurality of
gateways using the certificate to authenticate the security device,
wherein the security device attempts to establish VPN connections
with each of the plurality of gateways; and a memory coupled to the
processor and configured to provide the processor with
instructions.
15. The system recited in claim 14, wherein the security device
communicates with the portal at a portal address to register the
security device with the portal by executing a boot-up process or
script.
16. The system recited in claim 14, wherein the security device
receives a list of configured routes from a first gateway of the
plurality of gateways, wherein secure tunnels can then be
established using one or more of the configured routes, and wherein
for secure tunnels with duplicate routes, the security device is
configured to determine route metrics based on a priority of each
of the plurality of gateways.
17. The system recited in claim 14, wherein a first gateway of the
plurality of gateways is de-authorized, wherein de-authorization of
the first gateway includes one or more of the following: the
security device checking a revocation list at the portal, the
security device checking the revocation list at a VPN connection
with the first gateway, the security device checking the revocation
list at a re-key time, and removing a serial number associated with
the first gateway from the gateway configuration information stored
at the portal such that the first gateway can no longer renew its
certificate and/or does not automatically receive a new short term
life (STL) certificate.
18. The system recited in claim 14, wherein the security device is
de-authorized, wherein de-authorization of the security device
includes removing the serial number associated with the security
device from a portal configuration, and wherein the certificate for
the security device is automatically revoked.
19. The system recited in claim 14, wherein the security device
comprises a security appliance that includes a VPN client, and
wherein the configuration information further comprises a firewall
policy.
20. The system recited in claim 14, wherein the portal sends a
unique short term life (STL) certificate for each VPN client of the
plurality of gateways, and wherein the portal sends out new STL
certificates to each of the plurality of gateways prior to
expiration of the STL certificates.
21. The system recited in claim 14, wherein the certificate further
includes identification of one or more trusted certificate
authorities.
22. The system recited in claim 14, wherein each of the plurality
of gateways verifies that the certificate is from a trusted
certificate authority, and wherein each of the plurality of
gateways verifies that the certificate is still valid and has not
expired.
23. The system recited in claim 14, wherein the processor of the
security device is further configured to: receive a list of
configured routes from a gateway, wherein for tunnels with
duplicate routes, the security device maintains all tunnels and
sets high and low route metrics based on a priority of each of the
plurality of gateways.
24. The system recited in claim 14, wherein the processor of the
security device is further configured to: verify a portal
certificate using a list of trusted certificate authorities that
are pre-loaded on the security device.
25. The system recited in claim 14, wherein the processor of the
security device is further configured to: attempt to connect the
security device to a first gateway using the certificate to
authenticate the security device, wherein the first gateway is one
of the plurality of gateways to which the security device is
configured to connect using VPN connections, wherein the security
device attempts to establish a VPN connection with the first
gateway, and wherein the first gateway checks whether the
certificate has been revoked based on Online Certificate Status
Protocol (OCSP) status information, and in the event that the
certificate has been revoked, rejects the attempt from the security
device to establish the VPN connection.
26. A method, comprising: generating a public/private key pair and
a certificate signing request (CSR) using a processor of a security
device; sending the CSR to a portal over a public network to
authenticate the security device using a serial number associated
with the security device, wherein the CSR and the serial number are
verified by the portal; receiving a certificate from the portal for
using to establish virtual private network (VPN) connections and
configuration information for the security device, wherein the
certificate includes a credential signed by the portal as a trusted
certificate authority, and wherein the configuration information
includes gateway configuration information identifying a plurality
of gateways to which the security device is configured to connect
using VPN connections; and attempting to connect the security
device to each of the plurality of gateways using the certificate
to establish VPN connections with each of the plurality of
gateways.
Description
CROSS REFERENCE TO OTHER APPLICATIONS
[0001] This application is a continuation of co-pending U.S. patent
application Ser. No. 14/596,062, entitled CREDENTIALS MANAGEMENT IN
LARGE SCALE VIRTUAL PRIVATE NETWORK DEPLOYMENT, filed Jan. 13,
2015, which is a continuation of U.S. patent application Ser. No.
13/754,796, now U.S. Pat. No. 8,966,260, entitled CREDENTIALS
MANAGEMENT IN LARGE SCALE VIRTUAL PRIVATE NETWORK DEPLOYMENT filed
Jan. 30, 2013, both of which are incorporated herein by reference
for all purposes.
BACKGROUND OF THE INVENTION
[0002] A virtual private network (VPN) extends a private network
and the resources contained in the private network across public
(e.g., untrusted) networks such as the Internet. For example, a VPN
can enable a host computer to send and receive data across shared
or public, untrusted networks by emulating the properties of the
private network, such as shares, server access, and printers by
establishing and maintaining certain security and management
policies of the private network. This is generally implemented by
establishing a virtual point-to-point connection through the use of
either a dedicated connection or through a secure connection (e.g.,
secure network communications using various encryption techniques),
or a combination of both.
[0003] A VPN connection across the Internet logically operates as a
wide area network (WAN) link between the sites. A secure connection
across the Internet appears to a user as a private network
communication. However, this communication actually occurs over a
public, untrusted network (e.g., the Internet), which is, thus,
referred to as a virtual private network.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] Various embodiments of the invention are disclosed in the
following detailed description and the accompanying drawings.
[0005] FIG. 1 is a functional block diagram illustrating an
architecture for credentials management in large scale VPN
deployment in accordance with some embodiments.
[0006] FIG. 2 is a flow diagram illustrating credentials management
in large scale VPN deployment in accordance with some
embodiments.
[0007] FIG. 3 is a protocol flow diagram illustrating credentials
management in large scale VPN deployment in accordance with some
embodiments.
[0008] FIG. 4 is a functional block diagram illustrating a logical
architecture for credentials management in large scale VPN
deployment in accordance with some embodiments.
[0009] FIG. 5 is another flow diagram illustrating credentials
management in large scale VPN deployment in accordance with some
embodiments.
[0010] FIG. 6 is another flow diagram illustrating credentials
management in large scale VPN deployment in accordance with some
embodiments.
[0011] FIG. 7 is another flow diagram illustrating credentials
management in large scale VPN deployment in accordance with some
embodiments.
[0012] FIG. 8 is a computer screen diagram of a graphical user
interface of a portal for configuring and managing credentials
management in large scale VPN deployment in accordance with some
embodiments.
[0013] FIG. 9 is another computer screen diagram of a graphical
user interface of a portal for configuring and managing credentials
management in large scale VPN deployment in accordance with some
embodiments.
[0014] FIG. 10 is another computer screen diagram of a graphical
user interface of a portal for configuring and managing credentials
management in large scale VPN deployment in accordance with some
embodiments.
DETAILED DESCRIPTION
[0015] The invention can be implemented in numerous ways, including
as a process; an apparatus; a system; a composition of matter; a
computer program product embodied on a computer readable storage
medium; and/or a processor, such as a processor configured to
execute instructions stored on and/or provided by a memory coupled
to the processor. In this specification, these implementations, or
any other form that the invention may take, may be referred to as
techniques. In general, the order of the steps of disclosed
processes may be altered within the scope of the invention. Unless
stated otherwise, a component such as a processor or a memory
described as being configured to perform a task may be implemented
as a general component that is temporarily configured to perform
the task at a given time or a specific component that is
manufactured to perform the task. As used herein, the term
`processor` refers to one or more devices, circuits, and/or
processing cores configured to process data, such as computer
program instructions.
[0016] A detailed description of one or more embodiments of the
invention is provided below along with accompanying figures that
illustrate the principles of the invention. The invention is
described in connection with such embodiments, but the invention is
not limited to any embodiment. The scope of the invention is
limited only by the claims and the invention encompasses numerous
alternatives, modifications and equivalents. Numerous specific
details are set forth in the following description in order to
provide a thorough understanding of the invention. These details
are provided for the purpose of example and the invention may be
practiced according to the claims without some or all of these
specific details. For the purpose of clarity, technical material
that is known in the technical fields related to the invention has
not been described in detail so that the invention is not
unnecessarily obscured.
[0017] A virtual private network (VPN) extends a private network
and the resources contained in the private network across public
(e.g., untrusted) networks such as the Internet. For example, a VPN
can enable a host computer to send and receive data across shared
or public, untrusted networks by emulating the properties of the
private network, such as shares, server access, and printers by
establishing and maintaining certain security and management
policies of the private network. This is generally implemented by
establishing a virtual point-to-point connection through a secure
connection (e.g., secure network communications using various
encryption techniques).
[0018] A VPN connection across the Internet logically operates as a
wide area network (WAN) link between the sites. A VPN connection
can provide a secure connection across the Internet that appears to
a user as a private network communication. However, this
communication actually occurs over a public, untrusted network
(e.g., the Internet), which is, thus, referred to as a virtual
private network (VPN).
[0019] For example, VPNs can be either remote-access (e.g.,
connecting an individual computer to a network) or site-to-site
(e.g., connecting two networks together). In an enterprise
computing environment (e.g., for corporations, government
organizations, and/or other entities), remote-access VPNs can be
used to allow employees to access their company's intranet from
home or while traveling outside the office. Also, in an enterprise
computing environment, site-to-site VPNs can be used to allow
employees in geographically separated offices to share one cohesive
virtual network (e.g., Santa Clara and Palo Alto offices for a
company based in California can be connected using a site-to-site
VPN).
[0020] Thus, VPN systems can be used to provide such site-to-site
secure network connectivity for enterprise computing environments.
These VPN systems can use various protocols to securely tunnel
network traffic over untrusted, public networks and can be
implemented using various levels of security and related
requirements and configurations.
[0021] In particular, VPNs typically require remote access to be
authenticated and make use of encryption techniques to prevent
disclosure of private information. VPNs provide security through
tunneling protocols and security procedures, such as encryption.
VPNs can thereby provide for secure communications and confidential
data communications such that even if traffic is sniffed, an
attacker would only see encrypted data that he/she cannot
understand. VPN communications also allow for message integrity to
detect any instances of transmitted messages having been tampered
with or otherwise compromised.
[0022] Well known secure VPN protocols include the following:
Internet Protocol Security (IPSec); Transport Layer Security
(SSL/TLS); Datagram Transport Layer Security (DTLS); and various
other well-known VPN protocols. For example, when a VPN client
communicates with an enterprise's server, it prepares a packet
addressed to that server, encrypts it and encapsulates it in an
outer VPN packet, such as an IPSec packet. This packet is then sent
to the enterprise's VPN server (e.g., a server/firewall or other
security gateway or appliance) over the public Internet. The inner
packet is encrypted so that even if someone intercepts the packet
over the Internet, they cannot get any information from it (e.g.,
they can see that the remote host is communicating with a
server/firewall, but none of the contents of the communication can
be understood due to the encryption). Thus, using such VPN
techniques, secure communications can be provided over untrusted
(e.g., public) networks, such as the Internet.
[0023] Tunnel endpoints generally need to authenticate before
secure VPN tunnels can be established. User-created remote access
VPNs can use passwords, biometrics, two-factor authentication,
and/or other cryptographic techniques. Network-to-network VPN
tunnels often use digital certificates (e.g., certificates) and/or
passwords, as they permanently store the key(s) to allow the tunnel
to establish automatically and without user intervention.
[0024] Current approaches also typically require administrators
(e.g., Information Technology (IT), network, or security admins) to
manually configure, for example, hundreds to thousands of network
devices for secure communications across an enterprise (e.g., often
simply using a spreadsheet for configuration information for such
devices, to manually configure and manage the key exchange for each
of such devices). This approach clearly does not scale well as it
is inefficient and prone to human error. Also, existing approaches
often use a symmetric key implementation, such as from commercial
vendors (e.g., Cisco and other vendors), which would have a single
point of failure at the central authority of their symmetric key
system.
[0025] What are needed are improved techniques for credentials
management in large scale virtual private network (VPN)
deployment.
[0026] Accordingly, various techniques for credentials management
in large scale virtual private network (VPN) deployment are
disclosed. In some embodiments, using various techniques described
herein provides credentials management in large scale VPN
deployment and facilitates setting up dynamic VPN networks. For
example, these techniques can be used to implement a large scale
VPN network to facilitate VPN connections between network devices
(e.g., gateways, security appliances, and/or other network devices
that include VPN client functionality) in branch offices of an
enterprise to connect to enterprise gateways automatically with
manageable configuration steps. As another example, these
techniques can also be applied to corporate firewalls deployed in
branch locations in order to simplify and automate large VPN
network deployments.
[0027] In some embodiments, credentials management in large scale
VPN deployment includes generating a public/private key pair and a
certificate signing request at a satellite device; automatically
communicating the certificate signing request to a portal over a
public, untrusted network to authenticate the satellite device
using a serial number associated with the satellite device, in
which the certificate signing request and the serial number are
verified by the portal; and receiving a certificate from the portal
for using to establish VPN connections and configuration
information for the satellite device, in which the certificate
includes a credential signed by the portal as a trusted certificate
authority, and the configuration information includes gateway
configuration information identifying a plurality of gateways to
which the satellite device is configured to connect using VPN
connections. For example, asymmetric keys can be used with these
techniques, and, thus, this system does not have a single point of
failure problem, which is a shortcoming of symmetric key systems as
discussed above.
[0028] In some embodiments, the satellite device is a security
appliance that includes a VPN client, and the configuration
information further includes a firewall policy (e.g., one or more
firewall rules).
[0029] In some embodiments, the certificate is a short term life
certificate. In some embodiments, the portal sends a unique short
term life certificate to each VPN client of the plurality of
gateways. In some embodiments, the portal sends a unique short term
life certificate to each VPN client of the plurality of gateways,
and the portal automatically sends out new STL certificates to each
of the plurality of gateways prior to expiration of the STL
certificates (e.g., unless one or more of the gateways has been
configured to be removed from the gateway configuration, that is,
revoked).
[0030] In some embodiments, the certificate further includes
identification of one or more trusted certificate authorities. In
some embodiments, the authentication request is verified by the
portal using Public Key Infrastructure (PKI). In some embodiments,
the authentication request is verified by the portal using Public
Key Infrastructure (PKI), and the portal is a trusted certificate
authority.
[0031] In some embodiments, credentials management in large scale
VPN deployment further includes automatically connecting the
satellite device to each of the plurality of gateways using the
certificate to authenticate the satellite, in which the satellite
attempts to establish VPN connections with each of the plurality of
gateways.
[0032] In some embodiments, credentials management in large scale
VPN deployment further includes automatically connecting the
satellite device to a first gateway using the certificate to
authenticate the satellite, in which the first gateway verifies
that the certificate is from a trusted certificate authority (e.g.,
verifying the certificate chain), and in which the satellite
attempts to establish a VPN connection with the first gateway.
[0033] In some embodiments, credentials management in large scale
VPN deployment further includes automatically connecting the
satellite device to a first gateway using the certificate to
authenticate the satellite, in which the first gateway verifies
that the certificate has not been revoked (e.g., using Online
Certificate Status Protocol (OCSP) status information, such as by
checking an OCSP list via re-key time), and in which the satellite
attempts to establish a VPN connection with the first gateway.
[0034] In some embodiments, credentials management in large scale
VPN deployment further includes automatically connecting the
satellite device to a first gateway using the certificate to
authenticate the satellite, in which the first gateway verifies
that the certificate is still valid and has not expired, and in
which the satellite attempts to establish a VPN connection with the
first gateway.
[0035] In some embodiments, credentials management in large scale
VPN deployment further includes verifying a portal certificate
using a list of trusted certificate authorities that are pre-loaded
on the satellite device (e.g., installed on the device prior to
shipping the satellite device to a satellite office). In some
embodiments, an auto renewal process is provided, in which the
portal automatically renews the certificate (e.g., a short term
life certificate) for the satellite device (e.g., whenever the
satellite device connects to the portal or using some other push or
pull technique as further described herein with respect to various
embodiments).
[0036] In some embodiments, revocation of a gateway device is
provided. In some embodiments, revocation of a gateway device is
provided by revoking the serial number of the gateway device from
the gateway configuration maintained by the portal (e.g., including
removing the serial number from the OCSP list stored by the
portal). In some embodiments, revocation of a first gateway device
further includes a second gateway checking a revocation list at the
portal, a second gateway checking a revocation list at VPN
connection set-up, a second gateway checking a revocation at re-key
time, and/or removing a serial number from the gateway
configuration information stored at the portal (e.g., such that the
first gateway can no longer renew its certificate and/or does not
automatically receive a new short term life (STL) certificate,
which will eventually expire).
[0037] In some embodiments, the system includes a networking
device. In some embodiments, the system includes a gateway. In some
embodiments, the system includes a security appliance (e.g., an
integrated security appliance that includes VPN client
functionality as well as other security functionality, such as
firewall, intrusion detection/protection, content filtering, data
loss prevention, and/or other security functionality). In some
embodiments, the system includes a network routing device (e.g., a
network router). In some embodiments, the system includes a
programmed general purpose computer (e.g., a programmed computer,
laptop, tablet, or smart phone, or another type of a network
capable device with a general purpose processor that can execute
security software, including VPN client functionality).
[0038] FIG. 1 is a functional block diagram illustrating an
architecture for credentials management in large scale VPN
deployment in accordance with some embodiments. In some
embodiments, using various techniques described herein facilitates
automatically setting up dynamic VPN networks for a satellite
device 102 (e.g., that is deployed to a satellite office). In some
embodiments, a satellite device 102 includes a computing device,
such as a gateway, security appliance, network router, and/or some
other computing device that can perform VPN client functionality.
For example, these techniques can be used to implement a large
scale VPN network to facilitate VPN connections between gateways
and satellite devices in branch offices of an enterprise, such as
gateway 110 in Palo Alto, Calif., gateway 112 in Washington, D.C.,
and gateway 114 in New York, N.Y., to connect to such gateways via
the Internet 104 automatically with manageable and automated
configuration steps. In some cases, the satellite device 102 can be
automatically configured to establish VPN connections with each of
the gateways 110, 112, and 114 (e.g., and/or with a subset of such
gateways). In some cases, other satellite devices (not shown) can
be automatically configured to establish VPN connections with each
of the gateways 110, 112, and 114 (e.g., and/or with a subset of
such gateways). As another example, these techniques can also be
applied to corporate firewalls, security appliances, and/or other
computing/networking devices (e.g., that include VPN client
functionality) deployed in branch locations of an enterprise in
order to simplify and automate large VPN network deployments.
[0039] However, establishing a large scale VPN introduces several
problems. First, deploying a satellite device that is not
necessarily known or setup with a gateway it is connecting to,
requires a mutual authentication scheme without prior setup.
Accordingly, in some embodiments, for large scale VPN
authentication of the participating devices, mutually trusted
certificates, issued by either an external certificate authority
(CA) or issued by built-in certificate authority (CA) available
through a portal 106 is provided, as further described herein with
respect to various embodiments.
[0040] Second, to receive a certificate that can be used for
authentication requires some initial authentication as part of an
initial enrollment or boot strapping process. Accordingly, in some
embodiments, this authentication and authorization is performed
through the portal 106 and/or with user credentials (e.g., a user
name and password) following an authentication profile
configuration on the portal 106, as further described herein with
respect to various embodiments.
[0041] A third problem is an ability to automatically establish
proper bi-directional routing with the gateway(s). Accordingly, in
some embodiments, if dynamic routing, NAT, or any other
configurations or policy is required, it is either configured
manually or centrally through the portal 106, as further described
herein with respect to various embodiments.
[0042] In some embodiments, provisioning the satellite device 102
to securely communicate with a plurality of secure communication
tunnels (e.g., VPN tunnels) to connect networks, data centers at
remote sites over an untrusted, public network (e.g., the Internet
104) is provided. In some embodiments, VPN tunnels are established
between two or more endpoints, such as gateways and satellite
devices (e.g., using SSL, IPsec, and/or other secure communication
protocols to establish a secure tunnel), to facilitate secure
communications between such endpoints.
[0043] These techniques can facilitate automated deployment of
large scale VPN networks in various use case scenarios. As an
example, a large retailer can send out satellite devices (e.g.,
security appliances or other networking devices) to each of its
branch stores in twenty different cities in Maryland, New Jersey,
New York, and Virginia. The satellite devices can be initially
configured manually or through some other rapid deployment
mechanism. At each branch store, a local administrator enters a
portal address (e.g., a URL for communicating with the portal 106,
which can also be pre-configured in the satellite device such that
an administrator simply needs to connect the satellite device to
the network and boot-up the satellite device, which can execute a
boot-up process or script that includes automatically attempting to
connect to the portal using the portal address), and the satellite
device automatically registers with the portal (e.g., the portal
verifies the satellite device, and then the portal sends a
certificate and gateway configuration information to the satellite
device). This process can be performed for each of the satellite
devices at each of the branch stores. At this point, each of the
satellite devices can automatically establish VPN connections with
the enterprise gateways for the large retailer based on the gateway
configuration information (e.g., pre-configured gateway
configuration information). In some cases, the satellite devices
can be deployed in high availability pairs or as standalone
devices, and the satellite devices can also have redundant Internet
connections.
[0044] As another example, a portal administrator can manually add
a serial number of a new satellite (e.g., a new satellite device)
to a list of satellites. The new satellite is shipped to a remote
branch office. The local administrator at the remote branch office
can execute the initial setup of the new satellite including
entering a portal address so that the new satellite can communicate
with the portal. The new satellite authenticates to the portal by
communicating over the Internet, the new satellite device then
receives its certificate and gateway configuration information from
the portal, and the new satellite then establishes VPN tunnels with
each gateway based on the gateway configuration information and
using the certificate to authenticate the new satellite to each of
the gateways.
[0045] As yet another example, the portal administrator does not
add the serial number of the new satellite, but rather allows the
local administrator to authenticate on behalf of the new satellite
and register its serial number with the portal. In this use case
scenario, the local administrator can perform the initial setup
including entering the portal address (e.g., and committing the new
configuration). In this case, because the device cannot
authenticate to the portal with its serial number, the new
satellite notifies the local administrator and prompts for
authentication credentials (e.g., user credentials of an authorized
administrator, such as a user name and password). The engineer can
then enter the necessary authentication credentials, the device can
then authenticate to the portal. In response, a new satellite entry
is created at the portal for the newly authenticated satellite, and
the certificate and gateway configuration information are
downloaded to the new satellite. At this point, the new satellite
can then establish VPN tunnels with each gateway based on the
gateway configuration information and using the certificate to
authenticate the new satellite to each of the gateways. These and
various other use case scenarios will be apparent in view of the
various embodiments and techniques described herein.
[0046] In some embodiments, a portal (e.g., a central portal, such
as a Global Protect portal provided by Palo Alto Networks, Inc.)
provides a root certificate authority (CA) function for
implementing a PKI based secure network communication architecture
for a plurality of gateways or satellites (e.g.,
computing/networking devices, such as security appliances or other
networking devices that include VPN client functionality) using
secure communication channels (e.g., IP-SEC tunnels and/or using
some other secure communication protocols). In some embodiments,
upon boot-up of a satellite device 102, the satellite device 102
attempts to connect to the portal 106 (e.g., the portal address,
such as a URL, can be pre-configured on the satellite device before
it is shipped to a remote/branch office for deployment, or a local
administrator can enter the portal address locally at the satellite
device as part of the initial set-up). In some embodiments, the
satellite device 102 is configured to automatically authenticate to
the portal 106 (e.g., a central portal) and retrieve its
certificate(s) and configuration information (e.g., including
gateway configuration information) as further described herein with
respect to various embodiments.
[0047] In some embodiments, the portal 106 is a fully automated,
trusted certificate authority (CA) (e.g., using the Online
Certificate Status Protocol (OCSP)), which can provide certificates
(CERTs) to each device in the secure communication network. In some
embodiments, the satellite device 102 locally generates a unique
public/private key pair and then generates a Certificate Signing
Request (CSR) (e.g., the CSR can include the public key as well as
various meta data, such as names, dates/time-stamps, the serial
number of the satellite device, and the CSR is self-signed by the
satellite device using its private key). In some embodiments, this
process is performed each time the satellite device communicates
with the portal and communicates the CSR to the portal. The portal
can verify the CSR (e.g., to verify that the message is from that
satellite device) and then can extract the serial number and any
other meta data information included within the CSR, thereby
securely providing identifying information, such as the satellite
device's serial number to authenticate the satellite device. If the
portal has previously been configured to recognize that unique
serial number, then the portal can provision the satellite device
using various techniques as further described herein with respect
to various embodiments. Otherwise, the portal determines that the
VPN/security appliance needs to be configured. In this case, a
local administrator (e.g., an IT, network, or security admin) can
log-in remotely to the portal to configure the new satellite device
(e.g., logging in using admin username/password credentials and/or
other user identity verification techniques). The local admin can
then configure the portal to recognize the serial number of the new
satellite device and configure which other gateways/satellites that
this new satellite device should attempt to connect to. At this
point, provisioning the satellite device from the portal includes
receiving from the portal a unique certificate (e.g., a digital
certificate, such as a Short Term Life (STL) certificate) and
gateway configuration information (e.g., information for each of
the gateways to connect to), as well as a list of trusted
Certificate Authorities (CAs) (e.g., CAs that the satellite device
can trust certificates from, such as by region, such as an Americas
CA(s), an Asia Pacific (APAC) CA(s), EMEA CAs, and/or CAs for other
regions).
[0048] In some embodiments, once the satellite device has been
provisioned with a valid certificate and gateway configuration
information, the satellite device automatically initiates VPN
connections to each gateway that its gateway configuration
information indicates it should attempt to connect to. In
particular, the satellite device authenticates to all listed
gateways (e.g., as identified in its gateway configuration
information received from the portal) using its certificate,
exchanges routing information with such gateways, and establishes
tunnels with such gateways, as further described herein with
respect to various embodiments.
[0049] For example, if the satellite device 102 in Santa Clara,
Calif. attempts to connect to the gateway 110 in Palo Alto, Calif.,
then the satellite device 102 can send to the gateway 110 its
certificate (e.g., the STL certificate that the satellite device
102 received from the portal 106) in a request using its private
key to sign the request. In some embodiments, the certificate also
includes OCSP information to allow the gateway 110 in Palo Alto,
Calif. to verify the certificate with the CA (e.g., the portal 106
if that was the CA for the Americas, which can provide a
self-contained CA implementation). Further, the satellite device
102 in Santa Clara, Calif. will receive back a certificate for the
gateway 110 in Palo Alto, Calif., and the satellite device 102 can
verify that certificate with the identified CA (e.g., the portal
106 in this example, as discussed above). In addition, the
satellite device 102 in Santa Clara, Calif. can perform similar
processes to establish secure VPN connections with each of the
gateways that it is configured to connect to, including, for
example, each of the other gateways 112 and 114 as shown in FIG. 1.
Accordingly, using the various techniques described herein, a large
scale VPN deployment is provided to automatically establish secure
network connections from a satellite device with each of the
gateways.
[0050] In some embodiments, Short Term Life (STL) certificates are
used to facilitate management by requiring each gateway and
satellite in the large scale VPN deployment to automatically
attempt to renew their certificate periodically (e.g., every 24
hours, every 48 hours, once per week, and/or some other time
interval, using a push and/or pull renewal approach as further
described herein). Thus, if a gateway or a satellite is
de-authorized/revoked, then when that device attempts to renew, the
request will be denied as the portal will not issue a new STL
certificate to that device, and the STL certificate expires after a
predetermined period of time (e.g., 24 hours or some other time
interval).
[0051] In some embodiments, updated/new certificates are timely
sent (e.g., push renewal approach) to the gateways and satellites.
In some embodiments, updated/new certificates are requested (e.g.,
pull renewal approach) by the gateways and satellites. Devices may
need to be revoked for a variety of reasons, such as when a device
has been de-commissioned, an office closed/moved, a device was
compromised, a network configuration change, and/or various other
reasons. Accordingly, these techniques provide an efficient
approach for managing revocation of certificates for such devices
in a large scale VPN deployment (e.g., which can include hundreds
to thousands of devices). Also, these techniques provide a robust
approach for implementing revocation of certificates for such
devices in a large scale VPN deployment (e.g., as STL certificates
automatically become invalid upon expiration, which can be
determined even if the portal or OCSP responder is down or
otherwise unavailable, such that a device with an expired STL
certificate cannot establish or maintain VPN connections with other
devices in the large scale VPN deployment).
[0052] In some embodiments, the satellite request(s)/response(s)
can be implemented using XML or another format using asymmetric PKI
techniques. As discussed above, using asymmetric keys has various
advantages over symmetric keys. For example, when using a symmetric
keys approach, if the OCSP provider (e.g., server or portal that
implements the OCSP provider functionality) goes down or is
otherwise unavailable, then the entire secure network goes down.
Thus, symmetric keys approach has a single point of failure that
can cause the entire large scale VPN network to go down, and both
endpoints (e.g., both devices) generally must authenticate to the
OCSP if the secure network connection goes down. Also, revocation
is more difficult using the symmetric keys approach.
[0053] Accordingly, using various techniques disclosed herein
provides for an efficient, robust, and scalable large scale VPN
network that facilitates automated deployment techniques, and which
do not have a single point of failure as is present with other
approaches (e.g., implementations using symmetric keys). As
disclosed herein with respect to various embodiments, these
techniques also provide a more flexible approach that can
dynamically manage secure networks and facilitate more manageable
revocation techniques as described herein. Moreover, using various
techniques disclosed herein provides a scalable secure network
solution that is easy to implement and manage. For example, new
satellites can be pre-configured by a network administrator to make
set-up and install at a remote site easy by another employee at the
office for the enterprise (e.g., which need not have IT, network,
and/or security admin expertise).
[0054] FIG. 2 is a flow diagram illustrating credentials management
in large scale VPN deployment in accordance with some embodiments.
In some embodiments, a configuration flow of a satellite in
communication with a portal is implemented as shown in FIG. 2.
[0055] In some embodiments, an administrator (e.g.,
IT/network/security admin) performs an initial portal and gateway
configuration to set-up the infrastructure for a large scale VPN
deployment. For example, the administrator can perform the
certificate creation. The certificate creation process can include
creating a root certificate to be used with the portal, creating
SSL certificates for the portal and the gateway, configuring an
OCSP responder, selecting the location and the certificate
authority the OCSP responder is used for, entering the OCSP
responder URL for an Authority Information Access attribute, and
providing a service configuration, such as network interface, IP
address, and server certificate.
[0056] Also, the administrator can perform the portal setup. The
portal setup process can include creating a new portal
configuration and assigning the portal SSL certificate to it, and
also configuring the authentication and certificate profile and
assigning the portal configuration to a group of user accounts
(e.g., used to enroll new satellite devices).
[0057] Also, the administrator can perform the gateway setup. The
gateway setup process can include configuring the gateway and
setting access routes to be used with inbound clients.
[0058] Also, the administrator can perform the satellite settings
configuration. The configuring of the satellite settings can
include adding a list of serial numbers of satellite devices to the
configuration and defining a list of gateways for this
configuration, using the portal to perform such configurations. The
configuring of the satellite settings can further include selecting
an issue certificate, in order to issue a valid certificate to
clients with valid authentication credentials but an untrusted
certificate, selecting the root CA certificate created earlier to
be used for issuing client certificates, and selecting "Accept
published routes" so that the gateway firewall will install routes
published by the satellites.
[0059] Referring to FIG. 2, at 202, a satellite generates a key
pair and a certificate signing request (CSR) (e.g., the key pair is
used to generate the CSR as described herein). For example, the key
pair can be a public key and a private key pair based on public key
infrastructure (PKI) techniques. In PKI systems, a certificate
signing request (e.g., also referred to as a CSR or certification
request) is a message sent from an applicant to a certificate
authority to apply for a digital identity certificate (e.g.,
digital certificate or certificate). Before creating a CSR, the
applicant first generates a key pair (e.g., a public key and a
private key), keeping the private key secret. The CSR generally
includes information identifying the applicant (e.g., a
distinguished name in the case of an X.509 certificate, or as
described herein with respect to various embodiments, a unique
serial number of the device), and the public key generated by the
applicant. The CSR can be accompanied by other credentials or
proofs of identity required by the certificate authority, and the
certificate authority can also contact the applicant for further
information. In this example, the satellite generates the key pair,
and then generates a CSR using the key pair, in which the CSR also
includes the unique serial number of the satellite. The satellite
then sends the CSR to the portal in order to apply for a digital
identity certificate (e.g., digital certificate or certificate) for
the satellite and to obtain configuration information (e.g.,
including gateway configuration information) for the satellite, as
further described below.
[0060] At 204, the satellite sends the signed certificate request
(CSR) to the portal. For example, the CSR can also include the
unique serial number associated with the satellite, which can then
be used by the portal to verify the satellite and provide
configuration information (e.g., including gateway configuration
information) to the satellite in response to the CSR, as further
described below.
[0061] At 206, the portal attempts to verify the satellite based on
the CSR. In some embodiments, an initial enrollment of a satellite
includes authenticating the satellite with the portal using the
serial number of the satellite. In some embodiments, as part of an
initial enrollment of the satellite, the portal verifies the CSR,
and then also determines whether the serial number of the satellite
matches a serial number in the list of satellites as previously
configured with the portal. For example, a deployed satellite can
automatically attempt to communicate with the portal. In some
cases, the satellite can authenticate the portal's certificate
before accepting the connection with the portal. The satellite then
authenticates to the portal using its unique serial number (e.g.,
the serial number of the satellite can be included in the CSR, as
discussed above). The portal verifies the serial number using its
configured list of satellite devices. In some cases, if the serial
number cannot be verified (e.g., the serial number is not in the
configured list of satellite devices maintained by the portal),
then the portal returns an error message, as shown at 208. In some
cases, at this point, the portal can also prompt the administrator
to authenticate with the administrator's user credentials (e.g.,
and the portal can then attempt to verify the credentials provided
using the authentication profile configured in the portal
configuration, and successful initial enrollment is contingent on a
successful username/password-based authentication at this point).
After the satellite successfully connects to the portal for the
first time, the serial number in the user interface of the portal
can be augmented with the satellite's hostname. In some
embodiments, a new entry is created in the satellite list of the
large scale VPN configuration. In some embodiments, the portal
provides the portal configuration associated with the
authenticating user (e.g., if the configuration associated with the
satellite needs to be changed later, the administrator can move the
serial number to the corresponding portal configuration).
[0062] At 210 (e.g., the portal has successfully verified the
satellite), the portal sends the satellite a unique certificate
(CERT) and configuration information (e.g., including gateway
configuration information). For example, the portal can use a
configured issuing certificate to issue a new client certificate
(e.g., an IPSec client certificate) from the presented certificate.
The certificate and configuration information (e.g., including
gateway configuration information) can then be sent back to the
satellite. The satellite can store the certificate locally (e.g.,
securely stored in a cache/memory or other local storage element of
the satellite device). The satellite can also store the gateway
configuration information locally (e.g., stored in a cache/memory
or other local storage element of the satellite device, in which
such cached configuration information can be used if the portal
becomes unavailable, and, in some cases, the configuration
information can require updating/refreshing based on a
configuration lifetime parameter). In some cases, the satellite is
a security appliance, and the configuration information can include
configuration information for the security appliance, such as an
integrated security appliance that includes a VPN, firewall, and/or
other security functions such as intrusion detection/prevention,
content filtering, and/or data loss prevention (e.g., firewall
policy/rules, and/or other security configuration information can
be provided to the security appliance to further automate the
deployment and management of the remotely deployed security
appliance).
[0063] At 212, the satellite uses the certificate to attempt to
connect to one or more gateways based on the configuration
information. At 214, the satellite establishes VPN connections with
each of the gateways (e.g. based on the gateway configuration
information) using its certificate for authentication. For example,
the satellite can contact all available gateways using its
certificate for authentication. The satellite and gateway each
verify the presented certificates, respectively and check for
revocation. In particular, the VPN connection set-up can include
the satellite submitting a list of routes to the gateway (e.g., the
gateway will accept those that pass its route filter, and any
routes that are blocked will be reported back to the satellite).
Also, the gateway can provide the satellite with the list of
configured routes. IPSec tunnels can then be established. In
particular, IPSec key material can be exchanged in the SSL control
channel before establishing the IPSec tunnels. For tunnels with
duplicate routes, the branch firewall can maintain all tunnels and
set high and low route metrics based on the priority of the
gateways.
[0064] In some embodiments, certificates are short term life (STL)
certificates. At 216, the satellite receives another unique CERT
periodically (e.g., STL CERT(s) received from the portal, using a
push or pull renewal process as described herein). In some
embodiments, renewing certificates is automatically facilitated
using the portal (e.g., the portal can also serve as a trusted
certificate authority (CA)). For example, the portal can
periodically check a list of expiring certificates (e.g., every 24
hours or some other time interval). The portal can automatically
renew client certificates that will expire with a predetermined
period of time (e.g., for certificates that are within 5 days of
the expiration date of the SLT CERT). For clients (e.g.,
satellites) with such expiring certificates, when such a satellite
authenticates to the portal to retrieve its latest configuration
information and certificate, the portal sends the new STL CERT to
the satellite as well as the latest gateway configuration
information for the satellite. The satellite can then install the
new STL CERT and implement the new gateway configuration
information (e.g., the satellite rekeys its VPN connections to the
gateways using the new STL CERT).
[0065] At 218, the satellite does not receive a STL CERT, and
secured connections time-out after expiration of current STL CERT.
In some embodiments, VPN access to the gateways for the satellite
can be revoked for various reasons. For example, revoking satellite
access can be performed by having an administrator using the portal
to navigate to a satellite list and deleting the entry for the
particular satellite to be revoked (e.g., the serial number entry
is removed from the portal configuration such that the entry is
removed from the satellite list). As a result, the certificate is
automatically revoked (e.g., the OCSP responder can provide a
revocation status to participating devices to indicate which
certificates have been revoked, and each of the participating
devices can cache the most current revocation status provided by
the OCSP responder). In some cases, for ongoing authentication, if
the OCSP responder is unavailable, presented certificates can be
considered valid (e.g., not revoked), unless a revocation status is
cached and indicates that the certificate has been revoked.
However, the revoked satellite will not receive a new STL CERT, and
thus, the STL CERT currently installed and used by the satellite
eventually expires based on its expiration date. Thus, using such
techniques, even if the OCSP responder is unavailable, the
satellite would no longer be able to use the expired STL CERT to
establish or maintain VPN connections with the various
gateways.
[0066] In some embodiments, a new gateway can be added to the large
scale VPN deployment. For example, an administrator can log into
the portal device and create a new key and certificate using the
same issuing CA used to create the satellite and other gateway
certificates. The administrator exports the certificate (e.g., as a
PKCS12 file) and imports it into the gateway together with the
issuing CA certificate. The administrator configures the client
certificate profiles and the gateway. The administrator then adds
the IP address for the new gateway and configures the new gateway
configuration information associated with the gateway. Various
other approaches can be used to add a new gateway to the large
scale VPN deployment as will now be apparent to one of ordinary
skill in the art in view of the various embodiments described
herein.
[0067] In some embodiments, a gateway can be decommissioned from
the large scale VPN deployment. For example, an administrator can
log into the portal device and navigate to the certificates section
in the device configuration. The administrator then locates the
gateway certificate of the decommissioned gateway and revokes it.
The administrator navigates to the portal configuration and removes
the gateway's IP address from the portal configuration and commits
the new configuration. Various other approaches can be used to
decommission a gateway from the large scale VPN deployment as will
now be apparent to one of ordinary skill in the art in view of the
various embodiments described herein.
[0068] In some embodiments, CA certificate renewal is provided
using the portal. For example, the administrator can log into the
portal device and navigate to a certificate management screen in
the device section. The administrator selects the CA certificate
and clicks renew. The administrator is prompted to enter a new
expiration time (e.g., in days). The administrator commits the
configuration, which causes the renewed certificate to be written
to the portal configuration, and the renewed certificate is
provided to the satellite(s). The new certificate can then be
retrieved by each of the satellites and installed locally on each
of the satellites. Various other approaches can be used to provide
CA certificate renewal using the portal in the large scale VPN
deployment as will now be apparent to one of ordinary skill in the
art in view of the various embodiments described herein.
[0069] FIG. 3 is a protocol flow diagram illustrating credentials
management in large scale VPN deployment in accordance with some
embodiments. At 302, the satellite set-up process is performed
including generating a key pair (e.g., a public/private key pair,
as described above) and generating a certificate signing request
(CSR) (e.g., the CSR can include a serial number associated with
the satellite). At 304, the satellite sends the CSR to the portal
and authenticates to the portal using the unique serial number
associated with the satellite. At 306, the portal verifies the
serial number of the satellite presented with the CSR. At 308, if
the portal cannot verify the satellite based on the serial number,
then the portal requires authentication with a valid user account
(e.g., username and password credentials of an authorized user
logging into the portal). At 310, the portal issues a certificate
(e.g., with its own CA). At 312, the portal sends the certificate
and configuration information including gateway configuration
information (e.g., configuration information, certificate, and
certification chain) to the satellite. At 314, the satellite
installs the certificate, and the satellite attempts to connect to
available gateways (e.g., communicating using a secure sockets
layer (SSL) protocol) using the satellite's certificate for
authentication (e.g., and can measure connection performance). At
316, the gateways verify the satellite's certificate with the
portal (e.g., through the OCSP responder to determine whether the
certificate is still valid and has not been revoked, using the OCSP
protocol). At 318, the gateways and the satellite exchange routing
information about known and connected subnets (e.g., communicating
using SSL). At 320, the gateways and the satellite establish VPN
connections. For example, the gateways and the satellite can
exchange key material, cipher suites, and/or other
information/material to establish secure tunnels (e.g.,
communicating using IKE and IPSec protocols or other secure
communication protocols) and set routes/metrics based on gateway
performance.
[0070] FIG. 4 is a functional block diagram illustrating a logical
architecture for credentials management in large scale VPN
deployment in accordance with some embodiments. As shown, a
satellite device 402 includes a processor 404, a certificate 410
(e.g., received from the portal 420), configuration information 412
(e.g., including gateway configuration information and other
configuration information for the satellite device), and OCSP cache
414 (e.g., for caching OCSP status information received from the
OCSP responder 422). The satellite device 402 is in communication
with a portal 420 over the Internet 418.
[0071] As also shown, the portal 420 includes configuration
information 424 (e.g., gateway configuration information and
satellite device configuration information for one or more managed
satellite devices in a large scale VPN deployment). The portal 420
also includes an OCSP responder 422 for providing OCSP status
information to the gateways and satellite devices (e.g., satellite
device 402) in the large scale VPN deployment. In some embodiments,
each device (e.g., satellite and gateway device) is configured to
attempt to verify a serial number of a new device attempting to
connect to it using the OCSP list. In some embodiments, the OCSP
list is periodically cached in OCSP cache 414 (e.g., to avoid
having to communicate with the portal if the OCSP cache information
is still current, and/or if the portal is unavailable as described
herein with respect to various embodiments).
[0072] As also shown, a computing device 430 (e.g., a lap top,
desktop computer, work station, tablet, mobile phone, and/or other
computing device) is in communication with the satellite device 402
via a local connection 434 and is in communication with the portal
via the Internet 418 using a URL to access the portal (432).
[0073] FIG. 5 is another flow diagram illustrating credentials
management in large scale VPN deployment in accordance with some
embodiments. At 502, generating a public/private key pair and a
certificate signing request (CSR) is performed at a satellite
(e.g., satellite device). At 504, sending the CSR to a portal is
performed to request a device-based certificate (CERT) for the
satellite. At 506, the CERT for the satellite and gateway
configuration information are received. At 508, connecting to a
plurality of gateways based on the gateway configuration
information is performed using the CERT to authenticate the
satellite.
[0074] FIG. 6 is another flow diagram illustrating credentials
management in large scale VPN deployment in accordance with some
embodiments. At 602, a certificate signing request (CSR) is
received at a portal from a satellite (e.g., a satellite device).
At 604, the portal verifies the CSR from the portal (e.g.,
verifying the CSR and the serial number of the satellite, in which
the CSR includes the serial number of the satellite). At 606
(assuming the verification of the CSR was successful), the portal
generates a certificate (CERT) for the satellite. At 608, the
portal sends the CERT and gateway configuration information to the
satellite.
[0075] FIG. 7 is another flow diagram illustrating credentials
management in large scale VPN deployment in accordance with some
embodiments. At 702, a certificate (CERT) is revoked for a
satellite. At 704, the portal does not send out a new CERT (e.g.,
STL CERT) for the satellite (e.g., so that the STL CERT
installed/stored by the satellite eventually expires based on the
expiration period). At 706, one or more gateways and/or the portal
disconnect from the satellite based on the revoked and/or expired
CERT pursuant to the techniques described herein with respect to
various embodiments.
[0076] FIG. 8 is a computer screen diagram of a graphical user
interface of a portal for configuring and managing credentials
management in large scale VPN deployment in accordance with some
embodiments. As shown, an administrator can use the portal to
configure a satellite to connect with one or more gateways for a
large scale VPN deployment for an enterprise. Various other
interfaces can be provided to allow an administrator to use the
portal to configure a satellite to connect with one or more
gateways for a large scale VPN deployment for an enterprise as will
now be apparent to one of ordinary skill in the art in view of the
various embodiments described herein.
[0077] FIG. 9 is another computer screen diagram of a graphical
user interface of a portal for configuring and managing credentials
management in large scale VPN deployment in accordance with some
embodiments. As shown, an administrator can use the portal to view
a satellite tunnel status and run-time configuration of a large
scale VPN deployment for an enterprise. Various other interfaces
can be provided to allow an administrator to use the portal to view
a satellite tunnel status and run-time configuration of a large
scale VPN deployment for an enterprise as will now be apparent to
one of ordinary skill in the art in view of the various embodiments
described herein.
[0078] FIG. 10 is another computer screen diagram of a graphical
user interface of a portal for configuring and managing credentials
management in large scale VPN deployment in accordance with some
embodiments. As shown, an administrator can use the portal to view
a satellite tunnel status and run-time configuration of a large
scale VPN deployment for an enterprise. Various other interfaces
can be provided to allow an administrator to use the portal to view
a satellite tunnel status and run-time configuration of a large
scale VPN deployment for an enterprise as will now be apparent to
one of ordinary skill in the art in view of the various embodiments
described herein.
[0079] Although the foregoing embodiments have been described in
some detail for purposes of clarity of understanding, the invention
is not limited to the details provided. There are many alternative
ways of implementing the invention. The disclosed embodiments are
illustrative and not restrictive.
* * * * *