# 이메일 호스트명 인증서 불일치로 인한 Sidekiq 큐 과부하 및 심각한 사이트 불안정
**URL:** https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778
**Category:** Self-hosting
**Created:** [4월 30, 2022, 11:02오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778 "2022-04-30T23:02:36Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [4월 30, 2022, 11:02오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/1 "2022-04-30T23:02:36Z")
저는 수년간 Discourse를 자체 호스팅해 왔으며, 상당히 사양이 좋은 머신에서 여러 인스턴스를 안정적으로 구성하고 운영해 왔습니다.
오늘 갑자기 포럼 중 하나가 다운되어 있는 것을 발견했습니다. 처음 원인은 디스크 공간 부족으로 보였고, 이를 해결한 뒤 Discourse 인스턴스를 다시 시작했습니다.
하지만 그 이후로 인스턴스가 주기적으로 다운되고 있습니다. 부팅할 때마다 즉시 sidekiq가 폭주하고, 실패한 이메일 작업이 대량으로 발생하며, 이로 인해 redis에 막대한 양의 상태가 저장되고 있습니다. 이것이 실제 디스크 공간 문제의 원인이었다고 생각합니다. (다음에 머신을 올릴 때 flush를 수행할 예정입니다. 하지 않으면 이 머신의 공간이 금방 부족해져 Discourse를 시작해서 flush를 할 수도 없게 될 테니까요. 하지만 flush를 해도 redis 디스크 사용량이 크게 줄지는 않는 것 같습니다.)
에러 메시지는 인증서 이름 불일치에 관한 내용을 보여주고 있는데, 제가 사용하는 메일 서버는 내부 서버이고 TLS나 인증이 필요하지 않아서 다소 의외입니다. 같은 이메일 구성을 사용하는 다른 인스턴스에서도 이메일이 더 이상 작동하지 않는 것을 확인했습니다. 메인 프로덕션 로그에서는 422 에러만 보이지만, 비밀번호 재설정 같은 작업을 수행하면 sidekiq 로그에서 유사한 에러가 나타납니다:
```plaintext
Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)
```
명령줄을 통해 이메일을 보낼 수 있다는 것을 확인했으므로, 이는 메일 서버 자체의 문제가 아니라 Discourse 구성에 뭔가 문제가 있는 것으로 보입니다.
최근까지 정상적으로 작동했던 원래의 메일 구성은 다음과 같습니다:
```sh
DISCOURSE_SMTP_ADDRESS: outbound-relays.techservices.illinois.edu
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_ENABLE_START_TLS: false
```
다시 말하지만, 이 메일 서버는 내부 서버이며 사용자 이름이나 비밀번호가 필요하지 않습니다. 그리고 이 설정은 최근까지 정상적으로 작동했습니다. `DISCOURSE_SMTP_OPENSSL_VERIFY_MODE`를 실험해 보고 있지만, 이 옵션이 여전히 지원되는지 확신할 수 없습니다. 어쨌든 도움이 되지 않는 것 같습니다. 이 포럼들을 설정한 이후에 추가된 몇 가지 새로운 이메일 설정을 발견했지만, 이 메일 서버의 구성을 고려할 때 필요하지 않은 것 같습니다.
도움 주시면 감사하겠습니다! 지금은 컨테이너 재구축에 시간이 걸리고, 프로덕션 로그의 에러 메시지는 422 에러만 나와서 실제 근본 원인을 어디서 찾아야 할지 알 수 없어, 무엇이 문제인지 파악하거나 반복적으로 테스트하는 것조차 어려운 상태입니다. (어딘가에는 원인이 있을 텐데, 제가 그냥 놓치고 있는 것 같습니다.)
---
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [5월 1, 2022, 3:33오전 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/2 "2022-05-01T03:33:02Z")
추가 업데이트로, 다른 스레드의 조언에 따라 이 명령어를 사용하면 Docker 컨테이너 내부에서 이메일을 성공적으로 보낼 수 있습니다:
```sh
echo message | s-nail -r "noreply@myforum.com" -s testing -S "smtp=same.email-service.com:25" my@address.com
```
이는 이 문제가 발생했을 때 제가 사용하던 이메일 설정과 일치합니다. 또한 금요일에 최신 Discourse로 업그레이드하기 위해 (필수적인) 커맨드라인 pull을 수행했는데, 이로 인해 최근 커밋에서 이 문제가 도입되었을 수도 있다는 의문이 듭니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [5월 1, 2022, 5:27오전 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/3 "2022-05-01T05:27:49Z")
컨테이너를 마지막으로 재빌드한 시점이 언제인가요?
또한, Redis 큐를 비웠나요?
---
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [5월 1, 2022, 2:03오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/4 "2022-05-01T14:03:38Z")
> [@pfaffman](#):
>
> 컨테이너를 마지막으로 재구축한 시점은 언제였나요?
금요일 오전으로 기억합니다. UI를 통한 일반적인 업데이트가 `launcher app rebuild`가 필요하도록 만들었습니다. 나중에 sidekiq 로그를 확인해 보니, 백로그가 컨테이너가 재구축된 무렵부터 시작되었던 것으로 보였습니다. 하지만 Redis 로그가 호스트의 모든 사용 가능한 스토리지를 소진하고 실제로 다운타임을 유발하기까지는 약 24시간이 걸렸습니다. 다만, sidekiq이 100% CPU 사용률로 점점 더 많은 실패한 이메일 작업을 재전송하려 필사적으로 노력하고 있었기 때문에, 그 시점까지 포럼은 아마도 느렸을 것입니다.
> [@pfaffman](#):
>
> 또한, Redis 큐를 비웠나요?
네.
하지만 Redis 디스크 사용량이 줄지 않은 것 같아 우려됩니다. 현재 `redis_data` 폴더는 플러시(flush) 이후에도 여전히 29GB 크기를 차지하고 있습니다. MongoDB와 마찬가지로 Redis도 디스크 할당을 반환하도록 하는 것이 어려운가요? 이 용량은 해당 머신의 사용 가능한 디스크 공간의 1/3에 해당하므로 문제가 될 것이지만, 우선 이메일이 다시 작동하도록 만드는 것을 우선시하고 이 문제는 나중에 처리하겠습니다.
---
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [5월 1, 2022, 2:13오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/5 "2022-05-01T14:13:18Z")
디버깅 참고 사항: 컨테이너 내부에서 커맨드 라인을 통해 Discourse가 사용하는 것과 동일한 코드 플로우를 사용하여 테스트 이메일을 보낼 수 있는 방법이 있나요? (이미 동작하는 것으로 확인된 다른 도구를 커맨드 라인에서 사용하는 방식이 아닌, Discourse의 실제 코드 경로를 따르는 방식을 의미합니다.) 현재 테스트 이메일을 보내려면 웹 UI를 조작한 후 로그를 뒤져서 무엇이 잘못되었는지 파악해야 하므로, 디버깅에 도움이 될 것입니다. (그동안 422 에러만 발견했을 뿐, 테스트 이메일 플로우를 사용할 때 생성되지 않는 sidekiq 로그를 제외하면 더 유용한 정보는 찾지 못했습니다.) 아니면 테스트 이메일 UI가 더 많은 디버깅 정보를 표시하도록 개선할 수 있을까요?
전반적으로, 대부분의 사용자는 초기 초대장 발송 등에 이메일이 필요하기 때문에 이메일이 정상적으로 작동하지 않으면 이 단계까지 도달하지 못할 것이라고 추측합니다. 하지만 이메일이 잘 작동하다가 갑자기 멈추는 경우, 디버깅 가능성이 제한적이라는 점을 발견했습니다. (또한 재시도 로직도 조정할 필요가 있을 수 있습니다. 이 경우 재시도가 너무 빠른 것 같습니다. 인증서 오류는 최초 시도 몇 초 후에 해결될 가능성이 낮을 테니까요…)
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [5월 1, 2022, 6:24오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/6 "2022-05-01T18:24:49Z")
[새로운 Discourse 설치에서 이메일 문제 해결하기](https://meta.discourse.org/t/troubleshooting-email-on-a-new-discourse-install/16326)를 참고해 보시는 것이 좋습니다. 아래 명령을 실행하고 싶으신 것 같습니다.
```
rake emails:test[user@domain]
```
---
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [5월 1, 2022, 6:53오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/7 "2022-05-01T18:53:38Z")
감사합니다! 도움이 되었습니다. 결과가 다음과 같습니다:
```bash
Testing sending to user@domain using outbound-relays.techservices.illinois.edu:25, username: with plain auth.
======================================== ERROR ========================================
UNEXPECTED ERROR
SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)
====================================== SOLUTION =======================================
This is not a common error. No recommended solution exists!
Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)
=======================================================================================
```
이제 컨테이너를 재구성하여 컨테이너와 `app.yml`이 동기화되어 있는지 확인하겠습니다. 하지만 전반적으로 `app.yml` 설정 파일에 사용자 이름이나 비밀번호가 제공되지 않았는데도 왜 plain auth를 사용한다고 표시되는지 조금 혼란스럽습니다.
이 문제를 버그로 재분류할 가치가 있을까요? 처음에는 망설였습니다. 이메일 관련 문제이고, 이 같은 오작동이 발생할 수 있는 방법이 많으며, 그 중 많은 부분이 제 실수나 외부 변경 사항의 조합일 수 있기 때문입니다. 하지만 제 판단으로는(AFAICT) 이 문제는 수년간 정상적으로 작동하던 설정이 `discourse_docker`의 최신 버전으로 업그레이드된 후 갑자기 멈춘 것을 나타내는 것 같습니다. 최근 설정 파일 처리 방식에 변경 사항이 있었을 가능성이 있을까요?
에러 메시지 자체에 관해서는—해당 머신의 인증서를 가져올 수 있었고, 실제로 인증서에는 다른 호스트 이름(같은 머신을 가리키는 다른 CNAME)이 나열되어 있습니다. 그러나 인증서 자체는 몇 년 전 것으로, 약 1년 전에 만료되었지만 최근에서야 이 에러가 발생하기 시작했습니다. 따라서 인증서의 변경이 문제를 일으킨 것이 아니라고 생각합니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [5월 1, 2022, 8:07오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/8 "2022-05-01T20:07:53Z")
해당 호스트에 연결하여 `STARTTLS`를 테스트하면 호스트 이름과 일치하지 않는 인증서를 받게 됩니다:
```plaintext
Certificate chain
0 s:/C=US/ST=California/L=Sunnyvale/O=Proofpoint, Inc./OU=ESP/CN=*.pphosted.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
```
아직 만료되지 않았습니다:
```plaintext
notBefore=Jun 12 00:00:00 2020 GMT
notAfter=Sep 14 12:00:00 2022 GMT
```
정방향 및 역방향 조회를 수행해 보니 메일 서버의 실제 이름은 `mx0a-00007101.pphosted.com`과 `mx0b-00007101.pphosted.com`입니다.
```plaintext
outbound-relays.techservices.illinois.edu. 22 IN A 148.163.139.28
outbound-relays.techservices.illinois.edu. 22 IN A 148.163.135.28
28.139.163.148.in-addr.arpa name = mx0b-00007101.pphosted.com.
28.135.163.148.in-addr.arpa name = mx0a-00007101.pphosted.com.
```
`.edu` 이름 대신 이 중 하나를 연결할 호스트 이름으로 변경해 보세요. 인증서를 변경할 필요는 없으며, 호스트 이름이나 코드 변경으로 해결될 수 있습니다. 하지만 오류 메시지는 정확합니다. 실제로 호스트 이름과 인증서가 일치하지 않는 상태입니다.
---
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [5월 1, 2022, 11:57오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/9 "2022-05-01T23:57:47Z")
@RGJ 감사합니다! 한번 시도해 보겠습니다.
다만, 해당 이름들이 향후 변경될 수 있고, 이 목적으로 교내 사용에 제공된 호스트네임과 일치하지 않아서 우려가 됩니다. `app.yml` 설정이나 다른 방법으로 이 오류를 비활성화할 수 있는 방법이 있을까요?
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [5월 2, 2022, 8:51오전 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/10 "2022-05-02T08:51:03Z")
제 접근 방식은 먼저 문제를 해결한 다음, 어떻게 더 나은 상태로 만들 수 있을지 알아보는 것이었습니다.
`DISCOURSE_SMTP_OPENSSL_VERIFY_MODE`를 `false`로 설정하면 되는데, 이미 그렇게 시도했다고 하셨네요.
---
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [5월 2, 2022, 1:07오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/11 "2022-05-02T13:07:15Z")
네, 맞아요! 그 말이 맞네요.
그 값을 `none`으로 설정해 보긴 했는데, `false`로 설정한 건 아닌 것 같아요. `false`로 시도해 볼게요.
---
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [5월 2, 2022, 1:43오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/12 "2022-05-02T13:43:38Z")
확인 결과 `false`는 작동하지 않는 것 같습니다. `none`을 다시 시도해 보겠습니다.
---
### Author:  [@Geoffrey\_Challen](https://meta.discourse.org/u/Geoffrey_Challen)
#### Post date: [5월 2, 2022, 2:36오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/13 "2022-05-02T14:36:57Z")
`none`가 작동하지 않는다는 것도 확인할 수 있습니다.
이것이 합리적인 동작인지 다소 막막합니다. `DISCOURSE_SMTP_ENABLE_START_TLS`가 `false`로 설정되어 있는데, 저처럼 이메일 전문가가 아닌 입장에서는 인증서가 이 실패에 관여하는 것이 혼란스럽게 느껴집니다. 만약 해당 머신에 인증서가 전혀 없다면 동일한 문제가 발생합니까? (물론 저는 이를 테스트할 수 없습니다.) 만약 그렇지 않다면, 더욱 이상해 보입니다.
어쨌든 당분간 임시 해결책을 사용하겠지만, 이 부분은 제게 이상하게 느껴집니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [5월 2, 2022, 6:49오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/14 "2022-05-02T18:49:14Z")
> [@Geoffrey\_Challen](#):
>
> 하지만 이 부분은 뭔가 이상하게 느껴집니다.
물론입니다. 메일 서버가 _starttls_를 필수로 요구한다면 starttls 설정을 무시할 수 있다고 생각할 수 있지만, `DISCOURSE_SMTP_OPENSSL_VERIFY_MODE`는 여전히 오류를 방지할 수 있어야 합니다.
누군가 이 문제를 재현할 수 있나요?
---
### Author:  [@mstm](https://meta.discourse.org/u/mstm)
#### Post date: [5월 6, 2022, 7:01오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/15 "2022-05-06T19:01:30Z")
@Geoffrey_Challen 어떻게 수정하셨나요?
오늘 포럼을 2.9.0.beta4([c99a6b10fb](https://github.com/discourse/discourse/commits/c99a6b10fbac84e9acd0825e7e41aa2f5d8646c4))로 업데이트했는데, 이제 동일한 오류가 발생합니다. discourse가 이메일을 보낼 수 없습니다:
`SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)`
VPS와 이메일 설정은 변경하지 않았습니다!
제 app.yml:
```plaintext
DISCOURSE_SMTP_ADDRESS: smtp.mydomain.info
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_USER_NAME: info@mydomain.info
DISCOURSE_SMTP_PASSWORD: "mypassword"
DISCOURSE_SMTP_ENABLE_START_TLS: false # (선택 사항, 기본값 true)
DISCOURSE_SMTP_DOMAIN: mydomain.info # (일부 제공업체에서 필수)
#DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.example.com # (알림을 보내는 주소)
```
> [@RGJ](#):
>
> `DISCOURSE_SMTP_OPENSSL_VERIFY_MODE`를 `false`로 설정하면 되겠지만, 이미 그렇게 시도했다고 하셨습니다.
시해봤는데 아무런 변화가 없습니다 …
이제 이메일을 보낼 수도 없고 TLS를 사용할 수도 없습니다. 어떻게 해야 하나요?
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [5월 6, 2022, 7:48오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/16 "2022-05-06T19:48:54Z")
이 명령을 실행하여 인증서가 어떤 호스트명에 해당하는지 확인해 보세요.
```plaintext
openssl s_client -connect smtp.mydomain.info:25 -starttls smtp -showcerts 2>&1|grep "depth=0"
```
물론 `smtp.mydomain.info`는 자신의 SMTP 서버 주소로 교체해야 합니다.
그런 다음 해당 호스트명을 사용하여 SMTP 서버에 접근할 수 있는지 확인해 보세요.
---
### Author:  [@mstm](https://meta.discourse.org/u/mstm)
#### Post date: [5월 6, 2022, 8:19오후 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/17 "2022-05-06T20:19:59Z")
도와주셔서 감사합니다 @RGJ
> [@RGJ](#):
>
> 서명이 발급된 호스트명이 무엇인지
호스트명은 `CN = *.aruba.it` 이므로 mydomain.info와는 다릅니다. 그리고 네, 호스트명과 telnet을 사용하여 SMTP 서버에 접근할 수 있습니다.
`./launcher rebuild app` 실행 전에는 모든 것이 완벽하게 작동했습니다.
하지만… `DISCOURSE_SMTP_ENABLE_START_TLS: false`로 설정되어 있는데 왜 계속 인증서를 찾으려 하는 걸까요?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [5월 7, 2022, 12:21오전 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/18 "2022-05-07T00:21:29Z")
> [@mstm](#):
>
> 이메일을 보내지 못하고 TLS도 사용할 수 없어요. 어떻게 해야 하나요?
인증서와 일치하는 이름으로 호스트에 액세스할 수 있습니다. 원하시는 호스트 이름을 인증서에 추가해 달라고 서버 관리자에게 요청할 수 있습니다.
> [@mstm](#):
>
> 왜 계속 인증서를 찾으려 하나요?
좋은 질문입니다. 하지만 위에서 제시한 조언을 따르시면 이 답변은 무의미해지리라 생각합니다.
또 하나의 질문은, 왜 메일 관리자가 당신을 위해 이를 망가뜨렸는가 하는 것입니다.
아마도 그 설정은 이전에 작동하다가 지금은 작동하지 않는 것일 수 있습니다. 그 원인을 찾는 것이 쉬운지, 아니면 호스트 이름을 변경해 문제를 해결할 수 있는지 확인하는 것이 쉬운지는 명확하지 않습니다.
---
### Author:  [@mstm](https://meta.discourse.org/u/mstm)
#### Post date: [5월 7, 2022, 5:58오전 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/19 "2022-05-07T05:58:09Z")
> [@pfaffman](#):
>
> 또 다른 질문은, 왜 메일 관리자가 당신에게 오류를 일으켰는지입니다.
아무도 변경 사항을 만들지 않았다고 확신합니다. 저는 [이 플러그인](https://meta.discourse.org/t/official-advertising-ad-plugin-for-discourse/33734)을 설치하기 위해 `./launcher rebuild`만 실행했을 뿐입니다.
> [@pfaffman](#):
>
> 인증서와 일치하는 이름으로 호스트에 액세스할 수 있습니다.
그러면 VPS의 호스트 이름을 `.aruba.it`로 끝나는 것으로 변경해야 하나요?
> [@mstm](#):
>
> CN = \*.aruba.it
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [5월 7, 2022, 10:15오전 UTC](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778/20 "2022-05-07T10:15:07Z")
> [@mstm](#):
>
> 그러면 VPS의 호스트명을 `.aruba.it`로 끝나는 이름으로 변경해야 하나요?
그렇게 들립니다.
이 문제를 일으킨 회귀(regression)가 있을 수 있지만, 호스트명을 변경하면 당장의 문제를 해결할 수 있을 것이라고 생각합니다.
[Next page](https://meta.discourse.org/t/email-hostname-certificate-mismatch-causing-sidekiq-queue-overload-severe-site-instability/225778.md?page=2)