Payara Server SSL 구성

Securing Payara Server with Custom SSL Certificate

08 Apr 2016

by Ondrej Mihályi 

One of the most common administration tasks with Payara Server, as well as with any web server, is to set up certificates to secure either HTTP protocol or remote access to Payara Server administration interface. You might have a self-signed certificate or a certificate signed by a trusted authority. In both cases it is pretty easy to add them to a Payara Server domain and use them to secure communication channels. 

Payara Server 및 웹 서버에서 가장 일반적인 관리 작업 중 하나는 HTTP 프로토콜이나 Payara Server 관리 인터페이스에 대한 원격 액세스를 보호하기 위해 인증서를 설정하는 것입니다. 자체 서명 된 인증서 또는 신뢰할 수있는 기관에서 서명 한 인증서가있을 수 있습니다. 두 경우 모두 Payara Server 도메인에 추가하고 커뮤니케이션 채널을 보호하는 데 사용하기가 쉽습니다

 

If you want to follow this guide with a new self-signed certificate, you can create it in one command using openssl:

 새로운 자체 서명 인증서로이 안내서를 따르려면 openssl을 사용하여 하나의 명령으로 작성할 수 있습니다.

openssl req -x509 -newkey rsa:4096 -keyout mycert.key -out mycert.crt -days 365

 

The process of securing your Payara Server with new certificates involves several steps, which are worth summarising here:

새로운 인증서를 사용하여 Payara Server를 보호하는 과정에는 다음과 같은 몇 가지 단계가 포함됩니다.

1. bundle public and private key into a single PKCS12 file
2. add bundled public and private key into the key store used by the Payara Server domain
3. add certificate public key to the trusted certificates in Payara Server domain - optional, but strongly encouraged
4. enable security on HTTP listener, if required
5. enable security on admin interface, if required

1. 공개 키와 개인 키를 하나의 PKCS12 파일에 묶음 2. Payara Server 도메인에서 사용하는 키 저장소에 번들 된 공개 키 및 개인 키 추가 3. Payara Server 도메인의 신뢰할 수있는 인증서에 인증서 공용 키 추가 - 선택 사항이지만 강력하게 권장 됨 4. 필요한 경우 HTTP Listener에서 보안을 활성화합니다. 5. 필요한 경우 관리 인터페이스에서 보안 사용

In order to follow this guide, you will need:

이 가이드를 따르려면 다음이 필요합니다.

• certificate file (public key) - we will name it mycert.crt (either self-signed or signed by certification authority)
• certificate private key - we will name it mycert.key
• alternatively, you might have a bundle with public and private key instead of mycert.crt and mycert.key
• Payara Server installation – we will use a domain named mydomain (your domain might be the default domain1 domain, or another built-in payaradomain, or a new domain you have created)

• 인증서 파일 (공개 키) - 이름을 mycert.crt (자체 서명 또는 인증 기관 서명)
• 인증서 개인 키 - 이름을 mycert.key로 지정합니다.
• 또는 mycert.crt 및 mycert.key 대신 공개 키 및 개인 키가 포함 된 번들이있을 수 있습니다.
• Payara Server 설치 - mydomain이라는 도메인을 사용합니다 (도메인이 기본 domain1 도메인이거나 다른 내장 payaradomain 또는 사용자가 생성 한 새 도메인 일 수 있음)

Instead of separate public and private key files, your keys might be already bundled. This is often the case with certificates signed by a trusted authority. If your bundle is in different format than PKCS12, you need to specify a different store type for some operations, or export the keys in PKCS12 format.

별도의 공개 키와 개인 키 파일 대신 키가 이미 번들되어있을 수 있습니다. 이것은 종종 신뢰할 수있는 기관이 서명 한 인증서의 경우입니다. 번들이 PKCS12와 다른 형식 인 경우, 일부 조작에 대해 다른 상점 유형을 지정하거나 키를 PKCS12 형식으로 내 보내야합니다.

 

For the purpose of this guide, it is not important whether the certificate is self-signed or it is signed by a certification authority. The only difference between them is how the certificates are obtained. If authentication is not a concern, for example if all the communication will be private and behind a firewall, then it is sufficient to use self-signed certificates. However, it is useful to obtain and use a CA certificate for HTTPS connections available to the outside world to increase trustfulness and prevent forgery attempts.

 이 안내서의 목적 상 인증서가 자체 서명되었는지 또는 인증 기관이 서명했는지는 중요하지 않습니다. 두 인증서의 유일한 차이점은 인증서를 얻는 방법입니다. 인증이 중요하지 않은 경우, 예를 들어 모든 통신이 개인용이고 방화벽 뒤에있는 경우 자체 서명 된 인증서를 사용하는 것만으로 충분합니다. 그러나 신뢰를 높이고 위조를 방지하기 위해 외부에서 사용할 수있는 HTTPS 연결에 대해 CA 인증서를 얻고 사용하는 것이 유용합니다.

Preparation 

In order to operate with keystores, we will use keytool executable available in bin directory of your JDK installation.

 

키 스토어로 작업하기 위해서, JDK 설치의 bin 디렉토리에있는 keytool 실행 파일을 사용할 것입니다.

All the configuration changes happen inside the config folder of your domain. In order to make the steps simple, we start by copying both certificate public and private key files into this folder - let's copy mycert.cer and mycert.key into <Payara_install>/glassfish/domains/mydomain/config. If you already have a bundle with public and private key, copy it to config directory - we will assume its file name is mycert.p12.

 모든 구성 변경은 도메인의 config 폴더에서 발생합니다. 단계를 간단하게하기 위해 인증서 공개 키와 개인 키 파일을 모두이 폴더에 복사하는 것으로 시작합니다. mycert.cer 및 mycert.key를 <Payara_install> / glassfish / domains / mydomain / config에 복사합니다. 이미 공용 키와 개인 키가있는 번들을 가지고 있다면 config 디렉토리로 복사하십시오 - 파일 이름은 mycert.p12라고 가정합니다.

It is also recommended to stop the Payara Server domain before proceeding with the steps. For some actions we will need to start the domain, but the guide will explicitly mention that.

 

또한 단계를 진행하기 전에 Payara Server 도메인을 중지하는 것이 좋습니다. 일부 작업의 경우 도메인을 시작해야하지만 안내서에 명시 적으로 언급되어 있습니다.

Change domain master password

Before we can access certificate keystores, we need to make sure that we set Payara Server domain master password. This password is used by the Payara Server to access keystores. You will need to use the same password to access keystores later.

인증서 키 스토어에 액세스하기 전에 Payara Server 도메인 마스터 비밀번호를 설정해야합니다. 이 비밀번호는 Payara Server가 키 스토어에 액세스하는 데 사용됩니다. 키 스토어에 나중에 액세스하려면 동일한 암호를 사용해야합니다.

The default master password is changeit. You may want to change it by following command:

 기본 마스터 비밀번호는 changeit입니다. 다음 명령을 사용하여 변경할 수 있습니다.

asadmin change-master-password --savemasterpassword=true mydomain

 

 

This command will ask you for a new master password. Please, remember it, as it will be also used to encrypt/decrypt the keystore files and to decrypt any included key bundles. Using --savemasterpassword=true will save the password to the disk so that asadmin start-domain command doesn't prompt for password. If you don't want to store the password, omit this option.

 이 명령은 새 마스터 비밀번호를 묻습니다. 키 스토어 파일을 암호화 / 복호화하고 포함 된 키 번들을 해독하는데도 사용되므로 기억하십시오. --savemasterpassword = true를 사용하면 암호가 디스크에 저장되므로 asadmin start-domain 명령에서 암호를 묻는 메시지를 표시하지 않습니다. 암호를 저장하지 않으려면이 옵션을 생략하십시오.

Add certificate public and private keys to the keystore

In order to secure inbound connections, such as HTTP listeners, we need to put the certificate keys into a keystore file keystore.jks in the domain config folder. Before we do that, we need to bundle the public and private key together into a PKCS12 bundle file. Mind that the final PKCS12 bundle file needs to be encrypted with the same password which we use as the domain master password. The bundle will be later added the a keystore accessed by Payara Server, which will use the domain master password to open the keystore and also decrypt all bundles inside it.

HTTP Listener와 같은 인바운드 연결을 보호하려면 인증서 키를 도메인 구성 폴더의 키 저장소 파일 keystore.jks에 넣어야합니다. 우리가하기 전에 공개 키와 개인 키를 PKCS12 번들 파일에 함께 묶어야합니다. 최종 PKCS12 번들 파일을 도메인 마스터 비밀번호로 사용하는 비밀번호와 동일한 비밀번호로 암호화해야 함을 명심하십시오. 번들은 Payara Server가 액세스하는 키 저장소에 나중에 추가됩니다.이 키 스토어는 도메인 마스터 비밀번호를 사용하여 키 저장소를 열고 그 내부의 모든 번들을 해독합니다.

The keytool command does not support creation of PKCS12 bundles, therefore we must use other means. There are different steps involved, depending on your operating system.

 keytool 명령은 PKCS12 번들 생성을 지원하지 않으므로 다른 방법을 사용해야합니다. 운영 체제에 따라 다른 단계가 있습니다.

Creation of the PKCS12 bundle in Linux

 

In Linux, creation of the bundle using openssl is pretty straightforward:

Linux에서 openssl을 사용하여 번들을 만드는 것은 매우 간단합니다.

 

openssl pkcs12 -export -in mycert.crt -inkey mycert.key -out mycert.p12 -name mydomain_certificate

 

 

Path to the public key is given by the -in option, path to the private key is given by -inkey option, and filename of the created bundle is given by -out option. We also need to give the bundle an alias by -name option.

You will be asked for a new password to the created bundle, which is essentially a new keystore, similar to cacerts.jks and keystore.jks.

You may also see what is inside the new bundle, using keytool:

 공개 키에 대한 경로는 -in 옵션으로 지정되며 개인 키의 경로는 -inkey 옵션으로 지정되며 생성 된 번들의 파일 이름은 -out 옵션으로 지정됩니다. -name 옵션을 사용하여 번들에 별명을 부여해야합니다.

생성 된 번들에 대한 새로운 암호를 물어볼 것입니다.이 암호는 본질적으로 cacerts.jks 및 keystore.jks와 비슷한 새 키 저장소입니다.

keytool을 사용하여 새 번들 안에있는 내용을 볼 수도 있습니다.

keytool -list -keystore mycert.p12

 

 

Creation of the PKCS12 bundle in Windows

 

In order to create a bundle from mycert.crt and mycert.key, the most straightforward way is again using openssl, or some other similar tool (like MakeCert). However, they are not available in default Windows installation.

 mycert.crt와 mycert.key에서 번들을 생성하려면 가장 간단한 방법은 openssl이나 다른 유사한 도구 (예 : MakeCert)를 다시 사용하는 것입니다. 그러나 기본 Windows 설치에서는 사용할 수 없습니다.

If you already have a certificate signed by a trusted authority, you may import it into Windows store and export it in PKCS12 format, all using Microsoft Management Console (mmc). The signed certificate bundle must have exportable private key. If not, you might try to use the bundle as is - if it does not have PKCS12 format, you need to specify the correct format instead of PKCS12 in some commands later on.

신뢰할 수있는 기관에서 서명 한 인증서가 이미있는 경우 Microsoft Management Console (mmc)을 사용하여 인증서를 Windows 저장소로 가져 와서 PKCS12 형식으로 내보낼 수 있습니다. 서명 된 인증서 번들에는 내보낼 수있는 개인 키가 있어야합니다. 그렇지 않은 경우 번들을 그대로 사용하려고 시도 할 수 있습니다. PKCS12 형식이없는 경우 나중에 명령에서 PKCS12 대신 올바른 형식을 지정해야합니다.

When exporting the bundle, remember to check the option Yes, export the private key, as well as Include all certificates in the certification path if possible and Export all extended properties

번들을 내보낼 때 가능하면 인증서 경로에 모든 인증서 포함 및 모든 확장 속성 내보내기 옵션뿐만 아니라 예, 개인 키 내보내기 옵션을 선택해야합니다.

To be consistent with the rest of this guide, save the exported bundle into file named mycert.p12.

 

Microsoft Management Console does not provide an option to assign an alias to the certificate manually. It generates the alias for you, unfortunately the alias often appears like this: {fa2ds2d3-z13b-492d-2c83-f5z215432p2k}. This alias needs to be used later whenever we use alias mydomain_certificate in this guide.

 Microsoft Management Console에서는 인증서에 별칭을 수동으로 할당하는 옵션을 제공하지 않습니다. 별칭을 생성합니다. 불행히도 별칭은 {fa2ds2d3-z13b-492d-2c83-f5z215432p2k}와 같이 자주 나타납니다. 이 별칭은 나중에이 설명서에서 별칭 mydomain_certificate를 사용할 때마다 사용해야합니다.

Import the PKCS12 bundle to the keystore

 

In previous steps we have created a new keystore bundle with both public and private keys of your certificate. You may see what is inside the new bundle, using keytool:

 이전 단계에서는 인증서의 공개 키와 개인 키가 모두 포함 된 새 키 저장소 번들을 만들었습니다. keytool을 사용하여 새 번들 안에있는 내용을 볼 수 있습니다.

keytool -list -keystore mycert.p12

 

 

This command will ask for password given at creation of the bundle, and will list information about your certificate, together with the alias given to the certificate. The alias is important, as we will use it later to refer to our certificate.

 이 명령은 번들을 생성 할 때 주어진 암호를 묻고 인증서에 대한 정보와 인증서에 부여 된 별명을 나열합니다. 별칭은 나중에 중요하게 사용되어 인증서를 참조하게됩니다.

Finally, we need to import the PKCS12 bundle into the keystore in our Payara Server domain. The command keytool will gain do the trick:

마지막으로 PKCS12 번들을 Payara Server 도메인의 키 저장소로 가져와야합니다. keytool 명령은 트릭을 수행합니다.

keytool -importkeystore -destkeystore keystore.jks -srckeystore mycert.p12 -srcstoretype PKCS12 -alias mydomain_certificate

 

 

In the above command, we want to import into keystore.jks another keystore (our bundle) mycert.p12 of type PKCS12, and from that keystore we select only the certificate with alias mydomain_certificate.

위의 명령에서 우리는 PKCS12 유형의 또 다른 keystore (우리 번들) mycert.p12를 keystore.jks로 가져오고 그 키 스토어에서 별칭 mydomain_certificate가있는 인증서 만 선택하려고합니다.

Add certificate to the list of trusted certificates

This step involves adding the public key of your certificate or the whole PKCS bundle into the keystore file of trusted certificates in Payara Server domain. This is to make the server recognize the certificate as trusted, in case an external party or another Payara Server instance provide it. This step is optional, if you only intend to secure inbound channels, such as HTTP listeners. But it will do no harm to follow the procedure in any case.

 이 단계에서는 Payall Server 도메인의 신뢰할 수있는 인증서의 키 저장소 파일에 인증서의 공개 키 또는 전체 PKCS 번들을 추가합니다. 이것은 외부 또는 다른 Payara Server 인스턴스가 인증서를 제공 할 경우 서버가 인증서를 신뢰할 수있는 인증서로 인식하도록하기위한 것입니다. HTTP 수신자와 같은 인바운드 채널을 보호하려는 경우에만이 단계를 수행 할 수 있습니다. 그러나 어떠한 경우에도 절차를 따르는 데 아무런 해가 없습니다.

The default keystore file for trusted certificates can be found at <Payara_install>/glassfish/domains/mydomain/config/cacerts.jks.

신뢰할 수있는 인증서의 기본 키 저장소 파일은 <Payara_install> /glassfish/domains/mydomain/config/cacerts.jks에서 찾을 수 있습니다.

We need to import our public key file (mycert.crt) into the cacerts.jks keystore with following command:

 다음 명령을 사용하여 공개 키 파일 (mycert.crt)을 cacerts.jks 키 저장소로 가져와야합니다.

keytool -importcert -trustcacerts -destkeystore cacerts.jks -file mycert.crt -alias mydomain_certificate

 

The command will ask for password to the cacerts.jks keystore - this should be the same password as the domain master password.

이 명령은 cacerts.jks keystore에 대한 암호를 묻습니다.이 암호는 도메인 마스터 암호와 동일한 암호 여야합니다.

In case of PKCS bundle (mycert.p12), following command will do the same:

 PKCS 번들 (mycert.p12)의 경우, 다음 명령은 동일한 작업을 수행합니다.

keytool -importkeystore -destkeystore cacerts.jks -srckeystore mycert.p12 -srcstoretype PKCS12 -alias mydomain_certificate

 

 

The certificate will be installed under alias mydomain_certificate.

인증서는 별칭 mydomain_certificate 아래에 설치됩니다.

 

Replacing an old certificate

If you already have a certificate in your domain and you want to replace it because it will expire soon, you might want to replace it with a new one. In order to do it so that no further configuration changes in the domain are required, you need to remove the old certificate first, before installing the new certificate. Following keytool command will do that:

도메인에 이미 인증서가 있고 곧 만료되므로 교체하려는 경우 새 인증서로 교체 할 수 있습니다. 도메인에서 더 이상 구성을 변경할 필요가 없도록하려면 새 인증서를 설치하기 전에 먼저 이전 인증서를 제거해야합니다. 다음 keytool 명령을 사용하면됩니다.

 

keytool -delete -alias mydomain_certificate -keystore keystore.jks

 

 To replace the certificate also in trusted certificates keystore, issue the same command also for cacerts.jks file:

 신뢰할 수있는 인증서 keystore에서도 인증서를 바꾸려면 cacerts.jks 파일에도 동일한 명령을 실행합니다.

keytool -delete -alias mydomain_certificate -keystore cacerts.jks

 

After removing the old certificate, continue adding the certificate as described before. Just remember that the certificate is referred to in the domain configuration by its alias, therefore the alias of the new certificate must be the same as the alias of the old certificate.

 이전 인증서를 제거한 후에는 앞에서 설명한대로 인증서를 계속 추가하십시오. 인증서가 별칭으로 도메인 구성에서 참조되므로 새 인증서의 별칭이 이전 인증서의 별칭과 동일해야합니다.

If you want to replace the certificate used by secure admin, it is recommended to refresh all the secure admin settings by running command to turn on secure admin (even if it is already on):

 보안 관리자가 사용하는 인증서를 바꾸려면 안전 관리자를 사용하려면 (이미 켜져 있어도) 명령을 실행하여 모든 보안 관리자 설정을 새로 고치는 것이 좋습니다.

asadmin start-domain mydomain (if domain not yet started)
asadmin enable-secure-admin
asadmin restart-domain mydomain (to apply changes)

 

 

Enable security on HTTP listener

At this point, the certificate is available for use in your domain. You may use it to secure an HTTP listener or replace the default certificate for the listener http-listener-2, which is secured by default.

이 시점에서 귀하의 도메인에서 인증서를 사용할 수 있습니다. HTTP 리스너를 보호하거나 기본적으로 보안이 설정된 리스너 http-listener-2의 기본 인증서를 바꿀 수 있습니다.

First, we need to start the server with our domain.

먼저 도메인을 사용하여 서버를 시작해야합니다.

While server is running, we can use either asadmin or administration console in the web browser to configure the HTTP listener.

 서버가 실행되는 동안 웹 브라우저에서 asadmin 또는 관리 콘솔을 사용하여 HTTP Listener를 구성 할 수 있습니다.

Securing HTTP listener using admin console

 

Open admin console in your browser, by default it is located at http://localhost:4848/.

브라우저에서 관리 콘솔을 열면 기본적으로 http : // localhost : 4848 /에 있습니다

Go to Configurations -> server-config -> HTTP Service -> HTTP Listeners > my-http-listener, where my-http-listener is the HTTP listener you want to configure. By default, there already exists http-listener-2, which is already secured by TLS protocol, using default certificate with alias s1as and listens on port 8181.

구성 -> server-config -> HTTP 서비스 -> HTTP Listener> my-http-listener로 이동하십시오. 여기서 my-http-listener는 구성하려는 HTTP Listener입니다. 기본적으로 TLS 프로토콜로 보안이 설정된 http-listener-2가 이미 존재하며 별칭이 s1as 인 기본 인증서를 사용하고 포트 8181에서 수신합니다.

If you are adding security to an insecure listener, make sure that security is enabled, as in the following picture:

 안전하지 않은 수신기에 보안을 추가하려면 다음 그림과 같이 보안이 사용 가능한지 확인하십시오

 

On the SSL tab, TLS should be enabled. It is not recommended to enable SSL3, as it is superseded by TLS protocol and is not widely used. Moreover, there are some security issues with SSL3 protocol.

 SSL 탭에서 TLS를 사용하도록 설정해야합니다. SSL3은 TLS 프로토콜로 대체되어 널리 사용되지 않으므로 SSL3을 사용하도록 설정하지 않는 것이 좋습니다. 또한 SSL3 프로토콜에는 몇 가지 보안 문제가 있습니다

On the SSL tab, we also want to apply our new certificate - Certificate NickName should contain the alias of our certificate. In our case it is mydomain_certificate.

 SSL 탭에서 새 인증서를 적용하려고합니다. 인증서 닉네임에는 인증서의 별칭이 있어야합니다. 우리의 경우에는 mydomain_certificate입니다

 

If you are not sure about the alias of your certificate, use following command to find out its alias from the mycert.p12 bundle:

 인증서 별칭에 대해 잘 모르는 경우 다음 명령을 사용하여 mycert.p12 번들에서 별칭을 찾습니다

keytool -list -keystore mycert.p12

 

If you run the same command against keystore.jks file, you will see the same certificate among other certificates already in the domain keystore (there are already 2 certificates by default: glassfish-instance and s1as).

 keystore.jks 파일에 대해 동일한 명령을 실행하면 도메인 키 스토어에 이미있는 다른 인증서 중 동일한 인증서가 표시됩니다. 기본적으로 glassfish-instance 및 s1as라는 두 개의 인증서가 이미 있습니다

Finally, you may test the configuration changes in your web browser. With a web application deployed at context root webapp and listener using port 8181, open the following address and check that the connection is secured using the new certificate:  https://localhost:8181/webapp or https://<yourdomain>:8181/webapp.

 마지막으로 웹 브라우저에서 구성 변경 사항을 테스트 할 수 있습니다. 컨텍스트 루트 webapp 및 리스너에 웹 응용 프로그램을 배포하고 포트 8181을 사용하여 다음 주소를 열고 새 인증서 인 https : // localhost : 8181 / webapp 또는 https : // <yourdomain> : 8181 / webapp을 사용하여 연결이 보안되는지 확인합니다..

Securing HTTP listener using asadmin

With asadmin, each configuration step is represented by one or more asadmin CLI commands, which set configuration properties using dot notation:

asadmin을 사용하면 각 구성 단계가 점 표기법을 사용하여 구성 등록 정보를 설정하는 하나 이상의 asadmin CLI 명령으로 표시됩니다

• Make sure that the security is enabled for listener named http-listener-2:

http-listener-2라는 리스너에 대해 보안이 사용 가능한지 확인하십시오.

asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.security-enabled=true

• Make sure that TLS protocol is enabled for listener http-listener-2

리스너 http-listener-2에 대해 TLS 프로토콜이 사용 가능한지 확인하십시오. asadmin은 configs.config.ser를 설정합니다.

asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.tls-enabled=true
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.tls11-enabled=true
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.tls12-enabled=true

 

There are 3 versions of TLS protocol available. It is good practice to enable all 3 versions to degrade gracefully for older clients. But you may turn on only TLS 1.2 as well, if you only run the last command. You don't get such granularity when using admin console.

TLS 프로토콜에는 3 가지 버전이 있습니다. 구형 클라이언트의 경우 3 가지 버전 모두 정상적으로 성능 저하되도록하는 것이 좋습니다. 그러나 마지막 명령 만 실행하는 경우 TLS 1.2도 설정할 수 있습니다. 관리 콘솔을 사용할 때 이와 같은 세분성을 얻지 못합니다

• Apply our new certificate with alias mydomain_certificate to the listener http-listener-2:
• 새 인증서 인 mydomain_certificate을 http-listener-2 수신기에 적용합니다

asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.cert-nickname=mydomain_certificate

 

Turn on security on admin listener

It is possible to secure connections to admin console in a similar way as to any other HTTP listener. However, it is only recommended to turn on SSL security on admin listener when you need to access the admin console or run asadmin commands remotely and using the domain name that matches your certificate. Also mind that SSL will be used for communication between instances and domain admin server within a cluster.

 다른 HTTP Listener와 비슷한 방식으로 관리 콘솔에 대한 연결을 보호 할 수 있습니다. 그러나 관리 콘솔에 액세스하거나 원격으로 asadmin 명령을 실행하고 인증서와 일치하는 도메인 이름을 사용해야하는 경우에만 관리자 수신기의 SSL 보안을 켜는 것이 좋습니다. 또한 SSL은 클러스터 내의 인스턴스와 도메인 관리 서버 간의 통신에 사용됩니다

If you really need to secure admin listener, repeat the same steps in admin console as for other HTTP listeners, with following exceptions:

관리자 리스너의 보안을 정말로 필요로하는 경우 다음 예외를 제외하고 다른 HTTP 리스너의 경우와 동일한 단계를 관리 콘솔에서 반복하십시오.

before security is enabled for admin listener, ensure that all admin users have non-empty password

관리자 수신기에 대한 보안이 활성화되기 전에 모든 관리 사용자가 비어 있지 않은 암호를 갖고 있는지 확인하십시오

• if an admin user has empty password, change the password in admin console (Domain -> Administrator password), or using asadmin:

• 관리 사용자의 비밀번호가 비어있는 경우 관리 콘솔 (도메인 -> 관리자 비밀번호)에서 비밀번호를 변경하거나 asadmin을 사용하여 비밀번호를 변경하십시오.

asadmin change-admin-password

 

• to enable security for admin listener, use button Enable secure admin on Secure Administration page - a link to this page is provided under Security checkbox in admin-listener general configuration page, as well as through admin console menu: server (Admin server) -> General -> Secure Administration
• 보안 관리 페이지에서 보안 관리자 사용 -이 페이지에 대한 링크는 관리 리스너 일반 구성 페이지의 보안 확인란과 관리 콘솔 메뉴를 통해 제공됩니다. 서버 (관리 서버) -> 일반 -> 보안 관리
• you may set your certificate for admin listener using the Secure Administration page - replace s1as in the field Administration Aliaswith the alias of your certificate, or you may set your certificate later in the same way as with usual HTTP listeners. The latter option will mean that the default certificate will be used for connections to admin console until you set your certificate
• Secure Administration 페이지를 사용하여 admin listener에 대한 인증서를 설정할 수 있습니다. Administration Alias 필드의 s1as를 인증서의 별칭으로 바꾸거나 나중에 일반 HTTP Listener와 같은 방식으로 인증서를 설정할 수 있습니다. 후자의 옵션은 인증서를 설정할 때까지 기본 인증서가 관리 콘솔에 연결되는 데 사용됨을 의미합니다.
• note that after pressing Enable secure admin, the server will restart and you will be redirected to admin console running with  https protocol. If there are any other instances in the domain, you need to restart all of them as well.
• Enable secure admin (보안 관리 사용)을 누르면 서버가 다시 시작되고 https 프로토콜로 실행되는 관리 콘솔로 리디렉션됩니다. 도메인에 다른 인스턴스가있는 경우 모든 인스턴스도 다시 시작해야합니다.

Before admin security is enabled:

 

 

After admin security is enabled:

 

 

 

Again, secure admin listener can be enabled also by asadmin command:

 다시 asadmin 명령을 사용하여 보안 관리자 수신기를 활성화 할 수 있습니다.

asadmin enable-secure-admin --adminalias=mydomain_certificate

 

 

After this command you need to restart the server, as well as other instances in the domain.

이 명령 다음에 도메인의 다른 인스턴스는 물론 서버를 다시 시작해야합니다.

If you need to tweak the configuration further, you may use the same asadmin commands with admin-listener as with other HTTP listeners.

 구성을 추가로 조정해야하는 경우 다른 HTTP Listener와 마찬가지로 admin-listener와 동일한 asadmin 명령을 사용할 수 있습니다.

Summary

Hopefully you now understand how to add certificates into Payara Server and how to use them to secure communication with SSL. Although it is not difficult, it requires to do several steps, involving openssl, keytool and admin console. We have tried to provide explanation for all the necessary and optional steps, with alternative ways to accomplish them in different operating systems and using either admin console or asadmin. It is up to you to decide which approach fits you better to accomplish your security requirements.

Payara Server에 인증서를 추가하는 방법과 SSL을 사용하여 인증서를 사용하여 SSL과의 통신을 보호하는 방법을 잘 알고 있기를 바랍니다. 어려운 것은 아니지만 openssl, keytool 및 관리 콘솔과 관련된 여러 단계를 수행해야합니다. 우리는 필요한 모든 옵션 단계에 대한 설명을 제공하고 다른 운영 체제에서이를 수행하고 관리 콘솔 또는 asadmin을 사용하는 다른 방법을 제공하려고 노력했습니다. 어떤 접근 방식이 보안 요구 사항을 달성하는 데 더 잘 맞는지는 사용자가 결정할 것입니다.

https://blog.payara.fish/securing-payara-server-with-custom-ssl-certificate