代理最新帮助文档sql及帮助文档md文件提交
This commit is contained in:
duandongmei
File diff suppressed because one or more lines are too long
@@ -1,32 +1,112 @@
|
||||
#### [1.Function Introduction](#accordion1_1)
|
||||
Cache Policy
|
||||
|
||||
On National Proxy System, Individual Cache policy rules determine whether to cache or not based on traffic attributes, such as URL and Cookies.
|
||||
On National Proxy System, Individual Cache policy rules determine
|
||||
whether to cache or not based on traffic attributes, such as URL and
|
||||
Cookies. For cache action, the optimization parameters are:
|
||||
|
||||
#### [2.Action](#accordion1_2)
|
||||
*A Cache key* — is a unique string that lets the National Proxy System
|
||||
look for web content when requests hit them. It’s made up of a hostname,
|
||||
path, and cookie parts. By default, the Proxy use the entire URL as the
|
||||
cache key. Selecting the correct cache key will ensure maximum cache
|
||||
footprint and increase cache hits.
|
||||
|
||||
For cache action, the optimization parameters are:
|
||||
*Ignore Query String in URL* — in case the query strings doesn’t
|
||||
actually indicate that the object need to be different then you could
|
||||
EXCLUDE them from the cache key. For example, after ignoring “sqp” and
|
||||
“rs” of URL: “https://example.com/pic.jpg?~~sqp=UAAI&rs=AOn4~~”.
|
||||
|
||||
*Include Cookie Values* — in case the server send different content for
|
||||
the same URL based on the cookie value, you can include that cookie
|
||||
value as a part of cache key. For example, the server may set a cookie
|
||||
at the client called "prefLang=ru" to record user preferred language,
|
||||
you could add "prefLang" to distinguish different web content.
|
||||
|
||||
*Disable Revalidate* — is an ON-OFF switch. The pragma-no-cache header
|
||||
in a client’s request causes the proxy to re-fetch the entire object
|
||||
from the original server, even if the cached copy of the object is
|
||||
fresh. By default this option is switch OFF, which means a client’s
|
||||
non-conditional request results in a conditional GET request sent to the
|
||||
original server if the object is already in cache. The conditional
|
||||
request allows the original server to return the 304 Not Modified
|
||||
response, if the content in cache is still fresh. Thereby, the
|
||||
server-side bandwidth and latency consumed are lesser as the full
|
||||
content is not retrieved again from the original server.
|
||||
|
||||
*Cache Dynamic Content* — is an ON-OFF switch. A URL is considered
|
||||
dynamic if it ends in “.asp(x)” or contains a question mark (?), a
|
||||
semicolon (;), or “cgi”. *Ignore Query String* overrides this option
|
||||
(switch on).
|
||||
|
||||
*Cache Cookied Content* — is an ON-OFF switch. By default, the Proxy
|
||||
does NOT cache cookied content of any type. If this option is switch on,
|
||||
the system cache all cookied content except HTML.
|
||||
|
||||
*Ignore Request no-cache Headers* — is an ON-OFF switch. By default, the
|
||||
proxy strictly observes client Cache-Control: no-cache directives. As
|
||||
known as:
|
||||
|
||||
i. Authorization
|
||||
|
||||
ii. WWW-Authenticate
|
||||
|
||||
iii. Cache-Control: no-store
|
||||
|
||||
iv. Cache-Control: no-cache
|
||||
|
||||
If a requested object contains a no-cache header, then proxy forwards
|
||||
the request to the origin server even if it has a fresh copy in cache.
|
||||
You can configure proxy to ignore client no-cache directives such that
|
||||
it ignores no-cache headers from client requests and serves the object
|
||||
from its cache.
|
||||
|
||||
*Ignore Response no-cache Headers* — is an ON-OFF switch. By default, a
|
||||
response from an origin server with a no-cache header is not stored in
|
||||
the cache. As known as:
|
||||
|
||||
i. Cache-Control: no-store
|
||||
|
||||
ii. Cache-Control: private
|
||||
|
||||
iii. Set-Cookie
|
||||
|
||||
iv. Cache-Control: no-cache
|
||||
|
||||
v. WWW-Authenticate
|
||||
|
||||
vi. Expires header with a value of 0 (zero) or a past date.
|
||||
|
||||
If you configure proxy to ignore no-cache headers, then proxy also
|
||||
ignores no-store headers. The default behavior of observing no-cache
|
||||
directives is appropriate in most cases.
|
||||
|
||||
*Forcing Object Caching* — is an ON-OFF switch. You can force Proxy to
|
||||
cache specific URLs (including dynamic URLs) for a specified duration,
|
||||
regardless of Cache-Control response headers.
|
||||
|
||||
*Minimum Use* — sets the number of times an item must be requested by
|
||||
clients before Proxy caches it. This is useful if the cache is
|
||||
constantly filling up, as it ensures that only the most frequently
|
||||
accessed items are added to the cache. By default, Proxy cache object at
|
||||
its first appearance. The counter resets in every 30 minutes. Note that
|
||||
the requests is counted independently on each processing unit.
|
||||
|
||||
*Max Cache Object Size* — sets the upper limit of an object size, larger
|
||||
object will not be cached. By default, Proxy does not cache object
|
||||
larger than 1 GB.
|
||||
|
||||
*Cache Pinning Time* — configures Proxy to keep certain objects in the
|
||||
cache for a specified time. You can use this option to ensure that the
|
||||
most popular objects are in cache when needed and to prevent cache
|
||||
manager from deleting important objects. Proxy observes Cache-Control
|
||||
headers and pins an object in the cache only if it is indeed cacheable.
|
||||
|
||||
*Max Cache Size* — sets the upper limit of the size of storage for a
|
||||
policy. By default, Proxy uses all available disk space. When the cache
|
||||
size reaches the limit, the cache manager removes the files that were
|
||||
least recently used to bring the cache size back under the limit.
|
||||
|
||||
*Inactive Time* — specifies how long an item can remain in the cache
|
||||
without being accessed. A file that has not been requested for this time
|
||||
is automatically deleted from the cache by the cache manager, regardless
|
||||
of whether or not it has expired.
|
||||
|
||||
* A Cache key:is a unique string that lets the National Proxy System look for web content when requests hit them. It’s made up of a hostname, path, and cookie parts. By default, the Proxy use the entire URL as the cache key. Selecting the correct cache key will ensure maximum cache footprint and increase cache hits.
|
||||
* Ignore Query String in URL:in case the query strings doesn’t actually indicate that the object need to be different then you could EXCLUDE them from the cache key. For example, after ignoring “sqp” and “rs” of URL: “https://example.com/pic.jpg?sqp=UAAI&rs=AOn4”.
|
||||
* Include Cookie Values:in case the server send different content for the same URL based on the cookie value, you can include that cookie value as a part of cache key. For example, the server may set a cookie at the client called "prefLang=ru" to record user preferred language, you could add "prefLang" to distinguish different web content.
|
||||
* Disable Revalidate:is an ON-OFF switch. The pragma-no-cache header in a client’s request causes the proxy to re-fetch the entire object from the original server, even if the cached copy of the object is fresh. By default this option is switch OFF, which means a client’s non-conditional request results in a conditional GET request sent to the original server if the object is already in cache. The conditional request allows the original server to return the 304 Not Modified response, if the content in cache is still fresh. Thereby, the server-side bandwidth and latency consumed are lesser as the full content is not retrieved again from the original server.
|
||||
* Cache Dynamic Content:is an ON-OFF switch. A URL is considered dynamic if it ends in “.asp(x)” or contains a question mark (?), a semicolon (;), or “cgi”. Ignore Query String overrides this option (switch on).
|
||||
* Cache Cookied Content:is an ON-OFF switch. By default, the Proxy does NOT cache cookied content of any type. If this option is switch on, the system cache all Cookeid content except HTML.
|
||||
* Ignore Request no-cache Headers:is an ON-OFF switch. By default, the proxy strictly observes client Cache-Control: no-cache directives. As known as:
|
||||
* i. Authorization
|
||||
* ii. WWW-Authenticate
|
||||
* iii. Cache-Control: no-store
|
||||
* iv. Cache-Control: no-cache
|
||||
* If a requested object contains a no-cache header, then proxy forwards the request to the origin server even if it has a fresh copy in cache. You can configure proxy to ignore client no-cache directives such that it ignores no-cache headers from client requests and serves the object from its cache. Ignore Response no-cache Headers — is an ON-OFF switch. By default, a response from an origin server with a no-cache header is not stored in the cache. As known as:
|
||||
* i. Cache-Control: no-store
|
||||
* ii. Cache-Control: private
|
||||
* iii. Set-Cookie
|
||||
* iv. Cache-Control: no-cache
|
||||
* v. WWW-Authenticate
|
||||
* vi. Expires header with a value of 0 (zero) or a past date.If you configure proxy to ignore no-cache headers, then proxy also ignores no-store headers. The default behavior of observing no-cache directives is appropriate in most cases.
|
||||
* Forcing Object Caching: is an ON-OFF switch. You can force Proxy to cache specific URLs (including dynamic URLs) for a specified duration, regardless of Cache-Control response headers.
|
||||
* Minimum Use: sets the number of times an item must be requested by clients before Proxy caches it. This is useful if the cache is constantly filling up, as it ensures that only the most frequently accessed items are added to the cache. By default, Proxy cache object at its first appearance. The Counter resets in every 30 minutes. Note that the requests is counted in computing unit independently.
|
||||
* Max Cache Object Size: sets the upper limit of an object size, larger object will not be cached. By default, Proxy does not cache object larger than 1 GB.
|
||||
* Cache Pinning Time: configures Proxy to keep certain objects in the cache for a specified time. You can use this option to ensure that the most popular objects are in cache when needed and to prevent cache manager from deleting important objects. Proxy observes Cache-Control headers and pins an object in the cache only if it is indeed cacheable.
|
||||
* Max Cache Size: sets the upper limit of the size of storage for a policy. By default, Proxy uses all available disk space. When the cache size reaches the limit, the cache manager removes the files that were least recently used to bring the cache size back under the limit.
|
||||
* Inactive Time: specifies how long an item can remain in the cache without being accessed. A file that has not been requested for this time is automatically deleted from the cache by the cache manager, regardless of whether or not it has expired.
|
||||
@@ -1,24 +1,86 @@
|
||||
#### [1.Function Introduction](#accordion1_1)
|
||||
Control Policy
|
||||
|
||||
On National Proxy System, Individual Control policy rules determine whether to allow, block, redirect or replace a session based on traffic attributes, such as URL, request header fields, request body keywords, response header fields, response body keywords, IP address, Subscribe ID and their combination. You could specify these attributes in the submenu of Control Policy.
|
||||
|
||||
#### [2.Action](#accordion1_2)
|
||||
|
||||
You could select one of the five actions for above attributes, as known as:
|
||||
|
||||
* Monitor：the Proxy produce a log to record matched HTTP session information.
|
||||
* Block:the Proxy terminate matched HTTP session with an error page and produce a log. You MUST specify a Response Code and a Response Content to generate an error page.
|
||||
* Redirect: the Proxy redirect matched HTTP session to a predefined URL. Since redirection need to be performed before delivering response to client, condition of response body is not applicable in this action. You MUST configure the redirect response via Response Code and Response URL. The Response URL MUST start with a scheme (http:// or https://). You SHOULD NOT select 301 as Response Code unless you exactly know what you are doing. This action produces a log.
|
||||
* Replace:the Proxy Searches in a given HTTP part to Find a given string, and Replace any matches with another given string. If no match was found, the session remained untouched. For performance concerns, condition of request body and response body is not available in this action. For example, you can configure the Proxy to search in the response body of URL “www.example.com/index.html”, find every “string1” and replace with “string2”. This action produces a log.
|
||||
* Whitelist:the Proxy pass-through the matched sessions and produce no log.
|
||||
* In case of HTTP session matches one more policies, the priority order is Whitelist > Reject > Redirect > Replace > Monitor, action with higher priority overrides others.
|
||||
|
||||
#### [3.Attibutes](#accordion1_3)
|
||||
On National Proxy System, Individual Control policy rules determine
|
||||
whether to allow, block, redirect or replace a session based on traffic
|
||||
attributes, such as URL, request header fields, request body keywords,
|
||||
response header fields, response body keywords, IP address, Subscribe ID
|
||||
and their combination. You could specify these attributes in the submenu
|
||||
of *Control Policy*.
|
||||
|
||||
The attributes are detailed in following context:
|
||||
|
||||
* URL：From proxy’s perspective, a HTTP URL consists of a hierarchical sequence of three components: URL = hostname/path\[?query\] . The URL path name can also be specified by the user in the local writing system. If not already encoded, it is converted to UTF-8, and any characters not part of the basic URL character set are escaped as hexadecimal using percent-encoding; for example, search keywords “русский” in Google produces URL： https://www.google.com/search?q=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9 To perform policy action on above URL, you could input the whole URL in the input box. Or, you could input original keywords and let the Proxy do the decoding, e.g. “google.com/search” & “русский”. Note that the scheme string MUST be excluded from the URL, it’s “https://” in this case.
|
||||
* Request Header: is used to set conditions on request header fields. Header fields are colon-separated key-value pairs in clear-text string format, terminated by a carriage return (CR) and line feed (LF) character sequence. For example, “user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)“ is a header filed in request header. The Matching District is used to configure the field’s key, if the key was presented, the Proxy will search in the value for Keywords.
|
||||
* Response Header： is used to set conditions on response header fields. Its configuration is similar to Request Header.
|
||||
* Request Body：is used to set conditions on request’s body message. The Proxy searches the pre-configured Keywords in it. You can configure non-ASCII or non-utf8 keywords by turn on HEX.
|
||||
* Response Body：is used to set conditions on response’s body message. Its configuration is similar to Request Body.
|
||||
*URL* — From proxy’s perspective, a HTTP URL consists of a hierarchical
|
||||
sequence of three components: URL = hostname/path[?query] . The URL path
|
||||
name can also be specified by the user in the local writing system. If
|
||||
not already encoded, it is converted to UTF-8, and any characters not
|
||||
part of the basic URL character set are escaped as hexadecimal using
|
||||
percent-encoding; for example, search keywords “русский” in Google
|
||||
produces URL：
|
||||
|
||||
https://www.google.com/search?q=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9
|
||||
|
||||
To perform policy action on above URL, you could input the whole URL in
|
||||
the input box. Or, you could input original keywords and let the Proxy
|
||||
do the decoding, e.g. “google.com/search” & “русский”. Note that the
|
||||
scheme string MUST be excluded from the URL, it’s “https://” in this
|
||||
case.
|
||||
|
||||
NOTE Maximum HTTP/HTTPS URL length is 1023 characters
|
||||
|
||||
*Request Header* — is used to set conditions on request header fields.
|
||||
Header fields are colon-separated key-value pairs in clear-text string
|
||||
format, terminated by a carriage return (CR) and line feed (LF)
|
||||
character sequence. For example, “user-agent: Mozilla/5.0 (Windows NT
|
||||
10.0; Win64; x64)“ is a header filed in request header. The *Matching
|
||||
District* is used to configure the field’s key, if the key was
|
||||
presented, the Proxy will search in the value for *Keywords*.
|
||||
|
||||
*Response Header* — is used to set conditions on response header fields.
|
||||
Its configuration is similar to *Request Header*.
|
||||
|
||||
*Request Body* — is used to set conditions on request’s body message.
|
||||
The Proxy searches the pre-configured *Keywords* in it. You can
|
||||
configure non-ASCII or non-utf8 keywords by turn on HEX.
|
||||
|
||||
*Response Body* — is used to set conditions on response’s body message.
|
||||
Its configuration is similar to *Request Body*.
|
||||
|
||||
You could select one of the five actions for above attributes, as known
|
||||
as:
|
||||
|
||||
*Monitor* — the Proxy produce a log to record matched HTTP session
|
||||
information.
|
||||
|
||||
*Block* — the Proxy terminate matched HTTP session with an error page
|
||||
and produce a log. You MUST specify a *Response Code* and a *Response
|
||||
Content* to generate an error page.
|
||||
|
||||
*Redirect*—the Proxy redirect matched HTTP session to a predefined URL.
|
||||
Since redirection need to be performed before delivering response to
|
||||
client, condition of response body is not applicable in this action. You
|
||||
MUST configure the redirect response via *Response Code* and *Response
|
||||
URL*. The Response URL MUST start with a scheme (http:// or https://).
|
||||
You SHOULD NOT select **301** as *Response Code* unless you exactly know
|
||||
what you are doing. This action produces a log.
|
||||
|
||||
*Replace*—the Proxy *Searches in* a given HTTP part to *Find* a given
|
||||
string, and *Replace* any matches *with* another given string. If no
|
||||
match was found, the session remained untouched. For performance
|
||||
concerns, condition of request body and response body is not available
|
||||
in this action. For example, you can configure the Proxy to search in
|
||||
the response body of URL “www.example.com/index.html”, find every
|
||||
“string1” and replace with “string2”. This action produces a log.
|
||||
|
||||
*Whitelist*—the Proxy pass-through the matched sessions and produce no
|
||||
log.
|
||||
|
||||
National Proxy will enforce policy check on traffic attributes, policies
|
||||
have been created that there will be some that overlap or are subsets of
|
||||
the parameters that the policies use to determine which policy should be
|
||||
matched against the traffic. The execute order of policy is “first
|
||||
match, first served”. In case of an incoming traffic attribute matches
|
||||
one more policy, the priority order is *Whitelist \> Block \>
|
||||
Redirect \> Replace \> Monitor*, action with higher priority overrides
|
||||
others. If multiple policies of same action are matched, policy with
|
||||
bigger ID number is precedence.
|
||||
|
||||
|
||||
@@ -1,19 +1,63 @@
|
||||
#### [1.Function Introduction](#accordion1_1)
|
||||
Intercept Policy
|
||||
|
||||
On National Proxy System, Individual Intercept policy rules determines whether to intercept/optimize a connection based on traffic attributes, such as IP address, domain name and Subscribe ID. You could specify these attributes in IP Intercept and Domain Intercept.
|
||||
An Intercept policy rule allows you to define traffic that you want the
|
||||
National Proxy to decrypt and to define traffic that you choose to
|
||||
exclude from decryption because the traffic is personal or because of
|
||||
local regulations. A connection is intercepted/optimized based on
|
||||
traffic attributes, such as IP address, domain name (via SNI matching)
|
||||
and Subscribe ID. You could specify these attributes in *IP Intercept*
|
||||
and *Domain Intercept*.
|
||||
|
||||
#### [2.Action](#accordion1_2)
|
||||
Both *IP intercept* and *Domain Intercept* are subject two actions:
|
||||
|
||||
Both IP intercept and Domain Intercept are subject two actions:
|
||||
*Intercept*—the National Proxy System intercepts network traffic for
|
||||
further control policy and cache policy checking. Interception requires
|
||||
certificates to establish the National Proxy as a trusted third party.
|
||||
National Proxy deployed in transparent mode, which means the users don't
|
||||
have any proxy settings in their browser. When a connection is set to
|
||||
intercept, the proxy terminates the connection and initiates a new
|
||||
connection between client and server. If the connection is SSL
|
||||
encrypted, the original certificate is replaced with a substitute one.
|
||||
|
||||
* Bypass: the Proxy passes through the network connection without apply an optimization or policy checking. It’s could be used to bypass SSL pinning applications, such as Apple Store and WhatsApp, or a of a VIP’s IP address. In case of traffic matches one more policies, bypass overrides intercept.
|
||||
* Intercept: the National Proxy System intercepts network traffic for further control policy and cache policy checking. When a connection is set to intercept, the proxy terminates the connection and initiates a new connection between client and server. If the connection is SSL encrypted, the original certificate is replaced with a substitute one.
|
||||
*Bypass*—the Proxy passes through the network connection without apply
|
||||
an optimization or policy checking. You can also use bypass action when
|
||||
excluding servers from SSL decryption for technical reasons (the site
|
||||
breaks decryption for reasons such as certificate pinning, unsupported
|
||||
ciphers, or mutual authentication). Apple Store, WhatsApp, Telegram,
|
||||
Microsoft Windows Update are common SSL pinning application. In case of
|
||||
traffic matches one more policy, bypass overrides intercept.
|
||||
|
||||
When Intercept Related Domains is enabled, domains that share one certificates with the specified domain are considered as the same. For example, if the intercept facebook.com with Intercept Related Domain option, then *.xx.fbcdn.net, fb.com, .messenger.com and etc. are also intercepted. There may be side effects that intercept many different websites when they were hosted in a same CDN provider (Content Delivery Network).
|
||||
When *Intercept Related Domains* is enabled, domains that share one
|
||||
certificates with the specified domain are considered as the same. For
|
||||
example, if the intercept facebook.com with I*ntercept Related Domain*
|
||||
option, then \*.xx.fbcdn.net, fb.com, .messenger.com and etc. are also
|
||||
intercepted. There may be side effects that intercept undesired websites
|
||||
that share one certificate. For example, two websites hosted in a same
|
||||
CDN provider (Content Delivery Network) or different products of one
|
||||
company.
|
||||
|
||||
Key ring determines which certificate will be used to generate substitute certificate. You could configure key ring through Proxy Policy Object page. If no key ring is specified, proxy will use the default one.
|
||||
*Key ring* determines which certificate will be used to generate
|
||||
substitute certificate. You could configure key ring through *Proxy
|
||||
Policy Object* page. If no key ring is specified, proxy will use the
|
||||
default one.
|
||||
|
||||
Intercept policy produces no log. You can find out if the interception is successful by checking if the certificate is issued by your pre-configured Root CA. You need a PC which traffic has already directed to the Proxy, and a web browser to test the policy. For Chrome and Microsoft Internet Explorer, you could click the lock icon on the address bar to view certificate. For Firefox, after you clicking the lock icon, click “>” button to show connection details, click “more information”, and then click “view certificate”. If the browser warning that the connection is not secure, one possible reason is you haven’t install/trust the root certificate yet.
|
||||
Intercept policy produces no log. You can find out if the interception
|
||||
is successful by checking if the certificate is issued by your
|
||||
pre-configured Root CA. You need a PC which traffic has already directed
|
||||
to the Proxy, and a web browser to test the policy. For Chrome and
|
||||
Microsoft Internet Explorer, you could click the lock icon on the
|
||||
address bar to view certificate. For Firefox, after you clicking the
|
||||
lock icon, click “\>” button to show connection details, click “more
|
||||
information”, and then click “view certificate”. If the browser warning
|
||||
that the connection is not secure, one possible reason is you haven’t
|
||||
install/trust the root certificate yet.
|
||||
|
||||
**Note:** You should exercise caution because web applications may not
|
||||
cooperate with SSL interception. Reasons that sites break decryption
|
||||
technically include pinned certificates, mutual authentication,
|
||||
incomplete certificate chains, unsupported ciphers, and non-standard SSL
|
||||
implementation. If a site uses an incomplete certificate chain, the
|
||||
National Proxy doesn’t automatically fix the chain as a browser would.
|
||||
You need to manually download the missing sub-CA certificates and load
|
||||
and deploy them onto the proxy.
|
||||
|
||||
### Note: You should exercise caution because web applications may not cooperate with SSL interception, such as SSL pinning, mutual authentication or non-standard SSL implementation.
|
||||
@@ -1,154 +1,330 @@
|
||||
#### [1.Function Introduction](#accordion1_1)
|
||||
Proxy Policy Object
|
||||
|
||||
A policy object is a single object or a collective unit that groups discrete identities such as IP addresses, URLs, applications, or users. With policy objects that are a collective unit, you can reference the object in policy instead of manually selecting multiple objects one at a time. Typically, when creating a policy object, you group objects that require similar permissions in policy.
|
||||
A policy object is a single object or a collective unit that groups
|
||||
discrete identities such as IP addresses, URLs, applications, or users.
|
||||
With policy objects that are a collective unit, you can reference the
|
||||
object in policy instead of manually selecting multiple objects one at a
|
||||
time. Typically, when creating a policy object, you group objects that
|
||||
require similar permissions in policy.
|
||||
|
||||
#### [2.Key Ring](#accordion1_2)
|
||||
1. Key Ring
|
||||
|
||||
On National Proxy System, Key Ring is a pair of private key and public certificate. You can also import a certificate chain containing multiple certificates. Key Ring is a policy object, you can reference it in Intercept Policy. There are three Certificate Type:
|
||||
On National Proxy System, Key Ring is a pair of private key and public
|
||||
certificate. You can also import a certificate chain containing multiple
|
||||
certificates. Key Ring is a policy object, you can reference it in
|
||||
*Intercept Policy*.
|
||||
|
||||
* End-entity Certificate: is used for web servers to identify themselves. The Public Key File MUST be .p12 format that contains entire certificate chain. The Private Key File could be .pem, .key or .p12 format. This certificate type is not applicable to Domain Intercept for it cannot be used to sign other certificates. Expire After parameter is also not applicable to end-entity certificate for the same reason.
|
||||
* Intermedia Certificate: is used to sign other certificates. An intermediate certificate must be signed by another intermediate certificate, or a root certificate. The Public Key File MUST be .p12 format that contains entire certificate chain. The Expire After parameter indicates the expiration of the substitute certificate that was issued by this intermedia certificate.
|
||||
* Root Certificate: is used to sign other certificates. The Public Key File could be .der, .cer, .crt or .pem format. The Expire After parameter has the same meaning as Intermedia Certificate. Specification of certificate formats:
|
||||
* .pem- (Privacy-enhanced Electronic Mail) Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----"
|
||||
* .cer, .crt, .der – usually in binary DER form, but Base64-encoded certificates are common too (see .pem above)
|
||||
* .p12 – PKCS#12, may contain certificate(s) (public) and private keys (without password protected)
|
||||
There are three *Certificate Type:*
|
||||
|
||||
#### [3.Trusted Certificate](#accordion1_3)
|
||||
*End-entity Certificate*— is used for web servers to identify
|
||||
themselves. The *Public Key File* MUST be .p12 format that contains
|
||||
entire certificate chain. The Private Key File could be .pem, .key or
|
||||
.p12 format. This certificate type is not applicable to *Domain
|
||||
Intercept* for it cannot be used to sign other certificates. *Expire
|
||||
After* parameter is also not applicable to end-entity certificate for
|
||||
the same reason.
|
||||
|
||||
National Proxy System has a build-in trusted certificate authorities list. When the original certificate is issued by a certificate authority that not in the list, the proxy will issued the substitute certificate with an untrusted root certificate, and so consequently, the browser could identify unsecure connections.
|
||||
*Intermedia Certificate* — is used to sign other certificates. An
|
||||
intermediate certificate must be signed by another intermediate
|
||||
certificate, or a root certificate. The *Public Key File* MUST be .p12
|
||||
format that contains entire certificate chain. The *Expire After*
|
||||
parameter indicates the expiration of the substitute certificate that
|
||||
was issued by this intermedia certificate.
|
||||
|
||||
You can add a custom certificate authority to the trusted certificate authorities of the system.
|
||||
*Root Certificate* — is used to sign other certificates. The *Public Key
|
||||
File* could be .der, .cer, .crt or .pem format. The *Expire After*
|
||||
parameter has the same meaning as Intermedia Certificate.
|
||||
|
||||
*CRL* — or Certificate Revocation List, is a list of digital
|
||||
certificates that have been revoked by the issuing certificate authority
|
||||
(CA) before their scheduled expiration date and should no longer be
|
||||
trusted. On Key Ring settings, CRL is an HTTP URL that point to a valid
|
||||
.crl file. Invalid URL or .crl file may produce certificate warnings on
|
||||
some browser, i.e. Internet Explorer 11.
|
||||
|
||||
Specification of certificate formats:
|
||||
|
||||
*.pem* – (Privacy-enhanced Electronic Mail) Base64 encoded DER
|
||||
certificate, enclosed between "-----BEGIN CERTIFICATE-----" and
|
||||
"-----END CERTIFICATE-----"
|
||||
|
||||
*.cer, .crt, .der* – usually in binary DER form, but Base64-encoded
|
||||
certificates are common too (see .pem above)
|
||||
|
||||
*.p12* – PKCS\#12, may contain certificate(s) (public) and private keys
|
||||
(without password protected)
|
||||
|
||||
1. Trusted Certificate
|
||||
|
||||
National Proxy System has a build-in trusted certificate authorities
|
||||
list. When the original certificate is issued by a certificate authority
|
||||
that not in the list, the proxy will issued the substitute certificate
|
||||
with an untrusted root certificate, and so consequently, the browser
|
||||
could identify unsecure connections.
|
||||
|
||||
You can add a custom certificate authority to the trusted certificate
|
||||
authorities of the system.
|
||||
|
||||
The certificate MUST be PEM format.
|
||||
|
||||
Following are the National Proxy System’s default trusted certificate authorities:
|
||||
Following are the National Proxy System’s default trusted certificate
|
||||
authorities:
|
||||
|
||||
ACCVRAIZ1
|
||||
|
||||
Actalis Authentication Root CA
|
||||
|
||||
AddTrust External CA Root
|
||||
|
||||
AffirmTrust Commercial
|
||||
|
||||
AffirmTrust Networking
|
||||
|
||||
AffirmTrust Premium
|
||||
|
||||
AffirmTrust Premium ECC
|
||||
|
||||
Amazon Root CA 1
|
||||
|
||||
Amazon Root CA 2
|
||||
|
||||
Amazon Root CA 3
|
||||
|
||||
Amazon Root CA 4
|
||||
|
||||
Atos TrustedRoot 2011
|
||||
|
||||
Autoridad de Certificacion Firmaprofesional CIF A62634068
|
||||
|
||||
Baltimore CyberTrust Root
|
||||
|
||||
Buypass Class 2 Root CA
|
||||
|
||||
Buypass Class 3 Root CA
|
||||
|
||||
CA Disig Root R2
|
||||
|
||||
CFCA EV ROOT
|
||||
|
||||
COMODO Certification Authority
|
||||
|
||||
COMODO ECC Certification Authority
|
||||
|
||||
COMODO RSA Certification Authority
|
||||
|
||||
Certigna
|
||||
|
||||
Certinomis - Root CA
|
||||
|
||||
Class 2 Primary CA
|
||||
|
||||
Certplus Root CA G1
|
||||
|
||||
Certplus Root CA G2
|
||||
|
||||
Certum Trusted Network CA
|
||||
|
||||
Certum Trusted Network CA 2
|
||||
|
||||
Chambers of Commerce Root - 2008
|
||||
|
||||
AAA Certificate Services
|
||||
|
||||
Cybertrust Global Root
|
||||
|
||||
D-TRUST Root Class 3 CA 2 2009
|
||||
|
||||
D-TRUST Root Class 3 CA 2 EV 2009
|
||||
|
||||
DST Root CA X3
|
||||
|
||||
Deutsche Telekom Root CA 2
|
||||
|
||||
DigiCert Assured ID Root CA
|
||||
|
||||
DigiCert Assured ID Root G2
|
||||
|
||||
DigiCert Assured ID Root G3
|
||||
|
||||
DigiCert Global Root CA
|
||||
|
||||
DigiCert Global Root G2
|
||||
|
||||
DigiCert Global Root G3
|
||||
|
||||
DigiCert High Assurance EV Root CA
|
||||
|
||||
DigiCert Trusted Root G4
|
||||
|
||||
E-Tugra Certification Authority
|
||||
|
||||
EC-ACC
|
||||
|
||||
EE Certification Centre Root CA
|
||||
|
||||
Entrust.net Certification Authority (2048)
|
||||
|
||||
Entrust Root Certification Authority
|
||||
|
||||
Entrust Root Certification Authority - EC1
|
||||
|
||||
Entrust Root Certification Authority - G2
|
||||
|
||||
GDCA TrustAUTH R5 ROOT
|
||||
|
||||
GeoTrust Global CA
|
||||
|
||||
GeoTrust Primary Certification Authority
|
||||
|
||||
GeoTrust Primary Certification Authority - G2
|
||||
|
||||
GeoTrust Primary Certification Authority - G3
|
||||
|
||||
GeoTrust Universal CA
|
||||
|
||||
GeoTrust Universal CA 2
|
||||
|
||||
GlobalSign
|
||||
|
||||
GlobalSign
|
||||
|
||||
GlobalSign Root CA
|
||||
|
||||
GlobalSign
|
||||
|
||||
GlobalSign
|
||||
|
||||
Global Chambersign Root - 2008
|
||||
|
||||
Go Daddy Root Certificate Authority - G2
|
||||
|
||||
Hellenic Academic and Research Institutions ECC RootCA 2015
|
||||
|
||||
Hellenic Academic and Research Institutions RootCA 2011
|
||||
|
||||
Hellenic Academic and Research Institutions RootCA 2015
|
||||
|
||||
Hongkong Post Root CA 1
|
||||
|
||||
ISRG Root X1
|
||||
|
||||
IdenTrust Commercial Root CA 1
|
||||
|
||||
IdenTrust Public Sector Root CA 1
|
||||
|
||||
Izenpe.com
|
||||
|
||||
LuxTrust Global Root 2
|
||||
|
||||
Microsec e-Szigno Root CA 2009
|
||||
|
||||
NetLock Arany (Class Gold) Főtanúsítvány
|
||||
|
||||
Network Solutions Certificate Authority
|
||||
|
||||
OISTE WISeKey Global Root GA CA
|
||||
|
||||
OISTE WISeKey Global Root GB CA
|
||||
|
||||
OpenTrust Root CA G1
|
||||
|
||||
OpenTrust Root CA G2
|
||||
|
||||
OpenTrust Root CA G3
|
||||
|
||||
QuoVadis Root Certification Authority
|
||||
|
||||
QuoVadis Root CA 1 G3
|
||||
|
||||
QuoVadis Root CA 2
|
||||
|
||||
QuoVadis Root CA 2 G3
|
||||
|
||||
QuoVadis Root CA 3
|
||||
|
||||
QuoVadis Root CA 3 G3
|
||||
|
||||
SSL.com EV Root Certification Authority ECC
|
||||
|
||||
SSL.com EV Root Certification Authority RSA R2
|
||||
|
||||
SSL.com Root Certification Authority ECC
|
||||
|
||||
SSL.com Root Certification Authority RSA
|
||||
|
||||
SZAFIR ROOT CA2
|
||||
|
||||
SecureSign RootCA11
|
||||
|
||||
SecureTrust CA
|
||||
|
||||
Secure Global CA
|
||||
|
||||
Sonera Class2 CA
|
||||
|
||||
Staat der Nederlanden EV Root CA
|
||||
|
||||
Staat der Nederlanden Root CA - G2
|
||||
|
||||
Staat der Nederlanden Root CA - G3
|
||||
|
||||
Starfield Root Certificate Authority - G2
|
||||
|
||||
Starfield Services Root Certificate Authority - G2
|
||||
|
||||
SwissSign Gold CA - G2
|
||||
|
||||
SwissSign Silver CA - G2
|
||||
|
||||
T-TeleSec GlobalRoot Class 2
|
||||
|
||||
T-TeleSec GlobalRoot Class 3
|
||||
|
||||
TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1
|
||||
|
||||
TWCA Global Root CA
|
||||
|
||||
TWCA Root Certification Authority
|
||||
|
||||
TeliaSonera Root CA v1
|
||||
|
||||
TrustCor ECA-1
|
||||
|
||||
TrustCor RootCert CA-1
|
||||
|
||||
TrustCor RootCert CA-2
|
||||
|
||||
TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5
|
||||
|
||||
USERTrust ECC Certification Authority
|
||||
|
||||
USERTrust RSA Certification Authority
|
||||
|
||||
VeriSign Class 3 Public Primary Certification Authority - G4
|
||||
|
||||
VeriSign Class 3 Public Primary Certification Authority - G5
|
||||
|
||||
VeriSign Universal Root Certification Authority
|
||||
|
||||
VeriSign Class 3 Public Primary Certification Authority - G3
|
||||
|
||||
Visa eCommerce Root
|
||||
|
||||
XRamp Global Certification Authority
|
||||
|
||||
thawte Primary Root CA
|
||||
|
||||
thawte Primary Root CA - G2
|
||||
|
||||
thawte Primary Root CA - G3
|
||||
|
||||
Microsoft Root Authority
|
||||
|
||||
Microsoft Root Certificate Authority
|
||||
|
||||
Microsoft Root Certificate Authority 2010
|
||||
|
||||
Microsoft Root Certificate Authority 2011
|
||||
|
||||
Baltimore CyberTrust Root
|
||||
|
||||
* ACCVRAIZ1
|
||||
* Actalis Authentication Root CA
|
||||
* AddTrust External CA Root
|
||||
* AffirmTrust Commercial
|
||||
* AffirmTrust Networking
|
||||
* AffirmTrust Premium
|
||||
* AffirmTrust Premium ECC
|
||||
* Amazon Root CA 1
|
||||
* Amazon Root CA 2
|
||||
* Amazon Root CA 3
|
||||
* Amazon Root CA 4
|
||||
* Atos TrustedRoot 2011
|
||||
* Autoridad de Certificacion Firmaprofesional CIF A62634068
|
||||
* Baltimore CyberTrust Root
|
||||
* Buypass Class 2 Root CA
|
||||
* Buypass Class 3 Root CA
|
||||
* CA Disig Root R2
|
||||
* CFCA EV ROOT
|
||||
* COMODO Certification Authority
|
||||
* COMODO ECC Certification Authority
|
||||
* COMODO RSA Certification Authority
|
||||
* Certigna
|
||||
* Certinomis - Root CA
|
||||
* Class 2 Primary CA
|
||||
* Certplus Root CA G1
|
||||
* Certplus Root CA G2
|
||||
* Certum Trusted Network CA
|
||||
* Certum Trusted Network CA 2
|
||||
* Chambers of Commerce Root - 2008
|
||||
* AAA Certificate Services
|
||||
* Cybertrust Global Root
|
||||
* D-TRUST Root Class 3 CA 2 2009
|
||||
* D-TRUST Root Class 3 CA 2 EV 2009
|
||||
* DST Root CA X3
|
||||
* Deutsche Telekom Root CA 2
|
||||
* DigiCert Assured ID Root CA
|
||||
* DigiCert Assured ID Root G2
|
||||
* DigiCert Assured ID Root G3
|
||||
* DigiCert Global Root CA
|
||||
* DigiCert Global Root G2
|
||||
* DigiCert Global Root G3
|
||||
* DigiCert High Assurance EV Root CA
|
||||
* DigiCert Trusted Root G4
|
||||
* E-Tugra Certification Authority
|
||||
* EC-ACC
|
||||
* EE Certification Centre Root CA
|
||||
* Entrust.net Certification Authority (2048)
|
||||
* Entrust Root Certification Authority
|
||||
* Entrust Root Certification Authority - EC1
|
||||
* Entrust Root Certification Authority - G2
|
||||
* GDCA TrustAUTH R5 ROOT
|
||||
* GeoTrust Global CA
|
||||
* GeoTrust Primary Certification Authority
|
||||
* GeoTrust Primary Certification Authority - G2
|
||||
* GeoTrust Primary Certification Authority - G3
|
||||
* GeoTrust Universal CA
|
||||
* GeoTrust Universal CA 2
|
||||
* GlobalSign
|
||||
* GlobalSign
|
||||
* GlobalSign Root CA
|
||||
* GlobalSign
|
||||
* GlobalSign
|
||||
* Global Chambersign Root - 2008
|
||||
* Go Daddy Root Certificate Authority - G2
|
||||
* Hellenic Academic and Research Institutions ECC RootCA 2015
|
||||
* Hellenic Academic and Research Institutions RootCA 2011
|
||||
* Hellenic Academic and Research Institutions RootCA 2015
|
||||
* Hongkong Post Root CA 1
|
||||
* ISRG Root X1
|
||||
* IdenTrust Commercial Root CA 1
|
||||
* IdenTrust Public Sector Root CA 1
|
||||
* Izenpe.com
|
||||
* LuxTrust Global Root 2
|
||||
* Microsec e-Szigno Root CA 2009
|
||||
* NetLock Arany (Class Gold) Főtanúsítvány
|
||||
* Network Solutions Certificate Authority
|
||||
* OISTE WISeKey Global Root GA CA
|
||||
* OISTE WISeKey Global Root GB CA
|
||||
* OpenTrust Root CA G1
|
||||
* OpenTrust Root CA G2
|
||||
* OpenTrust Root CA G3
|
||||
* QuoVadis Root Certification Authority
|
||||
* QuoVadis Root CA 1 G3
|
||||
* QuoVadis Root CA 2
|
||||
* QuoVadis Root CA 2 G3
|
||||
* QuoVadis Root CA 3
|
||||
* QuoVadis Root CA 3 G3
|
||||
* SSL.com EV Root Certification Authority ECC
|
||||
* SSL.com EV Root Certification Authority RSA R2
|
||||
* SSL.com Root Certification Authority ECC
|
||||
* SSL.com Root Certification Authority RSA
|
||||
* SZAFIR ROOT CA2
|
||||
* SecureSign RootCA11
|
||||
* SecureTrust CA
|
||||
* Secure Global CA
|
||||
* Sonera Class2 CA
|
||||
* Staat der Nederlanden EV Root CA
|
||||
* Staat der Nederlanden Root CA - G2
|
||||
* Staat der Nederlanden Root CA - G3
|
||||
* Starfield Root Certificate Authority - G2
|
||||
* Starfield Services Root Certificate Authority - G2
|
||||
* SwissSign Gold CA - G2
|
||||
* SwissSign Silver CA - G2
|
||||
* T-TeleSec GlobalRoot Class 2
|
||||
* T-TeleSec GlobalRoot Class 3
|
||||
* TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1
|
||||
* TWCA Global Root CA
|
||||
* TWCA Root Certification Authority
|
||||
* TeliaSonera Root CA v1
|
||||
* TrustCor ECA-1
|
||||
* TrustCor RootCert CA-1
|
||||
* TrustCor RootCert CA-2
|
||||
* TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5
|
||||
* USERTrust ECC Certification Authority
|
||||
* USERTrust RSA Certification Authority
|
||||
* VeriSign Class 3 Public Primary Certification Authority - G4
|
||||
* VeriSign Class 3 Public Primary Certification Authority - G5
|
||||
* VeriSign Universal Root Certification Authority
|
||||
* VeriSign Class 3 Public Primary Certification Authority - G3
|
||||
* Visa eCommerce Root
|
||||
* XRamp Global Certification Authority
|
||||
* thawte Primary Root CA
|
||||
* thawte Primary Root CA - G2
|
||||
* thawte Primary Root CA - G3
|
||||
* Microsoft Root Authority
|
||||
* Microsoft Root Certificate Authority
|
||||
* Microsoft Root Certificate Authority 2010
|
||||
* Microsoft Root Certificate Authority 2011
|
||||
* Baltimore CyberTrust Root
|
||||
Reference in New Issue
Block a user