Nginx + Nuxt + VPSでWebサイトを公開！
みなさんこんにちは！ イザナギです！ 最近ポートフォリオサイトを作り直して「Heroku」にあげようと思ったのですが、 ビルド制限かかってしまったんですよね... なので、WebサイトはHerokuに上げられませんでした。 NuxtアプリをHerokuでデプロイしてみた！ どうしようかな？ そう迷った結果... URL取得してサーバー借りてデプロイしよう！という結論に至りました。 なので、今回はNuxtで開発したWebアプリをWebに公開までにしたことについて書いていきたいと思います！ サーバーの契約今回はconoHaVPSを使いたいと思います。 初めて契約される方は、ログインが必要です。 ログインし、VPSを契約します。 私は「CentOS Stream」を使ってみたかったので、「CentOS Stream」を選択しました。 他の設定は好みでいいと思います！ これで契約は終わりですが、ま
【AWS】S3+CloudFront+Route53+ACMでSSL化(https)した静的Webサイトを公開する
概要 本記事では、S3+CloudFront+Route53を利用して、静的サイトを公開する実装手順を紹介します。ACMを使ってSSL証明書を発行し、httpsで公開します。 LP（ランディングページ）、ポートフォリオサイト、シンプルなサイトなどをインターネット上に公開する際に役立ちます。 構成図 本記事のゴール 今回のゴールは、以下のhtml,ccs,画像だけのシンプルな静的Webサイトを、独自ドメインを使用してインターネット上に公開することです。 事前準備 AWSのアカウント 公開するファイル（html,css,imageなど） 実装手順 S3で静的Webサイトホスティングをする CloudFront経由でS3のファイルにアクセスする CloudFrontのOAIを使用して、S3への直接アクセスを制限する 独自ドメインを取得し、Route53へ設定する(freenomで無料ドメインを取
ACMでSSL証明書を発行してみた
ACM (AWS Certificate Manager)でRoute 53に登録してあるドメインのSSL証明書を発行してみました。 動画 ACMとは ・SSL/TLS証明書を簡単に発行、管理できるサービス ・無料で利用可能 ・自動更新可能 ・発行も数分で可能 詳しくは公式ドキュメントをご覧ください。 前提 Route 53でドメインを取得した状態から始めます。 Freenomやお名前.comのドメインをRoute 53に登録すればお安く試すこともできます。 手順 まずはACMコンソールに移動します。 証明書のプロビジョニングの「今すぐ始める」をクリックします。 「パブリック証明書のリクエスト」を選択し、「証明書のリクエスト」をクリックします。 ドメイン名を入力します。 ルートドメインではなく、www.example.comなどのサブドメインにも証明書をリクエストするには、*.ドメイン名を
SSL証明書がESETになっているしん
力強く 歌声が呼ぶ 魔法が働く 私は 知恵の眠りから目覚めた 誰が 私から眠りを 追い払うのか？ エルダ、「ニーベルングの指輪」より 私はオンプレミスで自宅にサーバーを設置してこのブログを稼働している。まぁ、本職だからね。 そして、SSLに関しては、Let's Encryptという無料のサーバー証明書を利用していて、しかもロボット化による自動更新になっているから、期限切れに伴う証明書入れ替えメンテナンスの手間もない。2か月に一度自動更新されるようになっている。 SSL通信の情報は、ブラウザのアドレスバー左端にある鍵のアイコンをクリックすると出てくる。試しに、私のブログをChromeで見てみると、当初ここにはLet's Encryptの証明書が表示されていた。 しかし。ESETというウイルス対策ソフトを入れた後から、ここに表示される証明書情報が、"ESET SSL Filter CA"となっ
Node.js で中間証明書が設定されていない Web サイトにアクセスする(コンテナ版) | zu-min.com
以前書いた記事では update-ca-trust を使用しましたが、今回は update-ca-certificates を使用します。事象としては同じで、以下のエラーが出ます。 { Error: unable to verify the first certificate at TLSSocket.onConnectSecure (_tls_wrap.js:1047:34) at TLSSocket.emit (events.js:182:13) at TLSSocket._finishInit (_tls_wrap.js:629:8) code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' } 実験用に Dockerfile を用意します。重要なのは ca-certificates パッケージをインストールする点です。また、NODE_EXTRA_CA_CERT
SSLサーバ証明書における2021年以降の仕様変更および業界動向
CA/Browser ForumおよびMozillaルートプログラムでは、全ての認証局（CA）が画一された要件の遵守と監査を義務付けられています。重要なコンプライアンスやセキュリティ要件の設定を通じて、ウェブサイトの閲覧者を保護しています。 SSLサーバ証明書の仕様なども度々アップデートがされ、OUフィールドの廃止要件の決定、またECC鍵使用の場合のKey Usageに関する追加情報の発表がありました。本記事では、直近の４つのSSLサーバ証明書の仕様変更について解説します。 SSLサーバ証明書の仕様変更 1. 【2021年10月1日～】認証局（CA）はドメイン名及びIPアドレスの審査を証明書発行以前の398日以内に実施 2. 【2021年12月1日～】ページ認証によるワイルドカード発行の禁止 3. 【2021年7月26日～】ECC鍵のKey Usageに対する変更 4. 【2022年8月3
DV、OV、IV、およびEV証明書-SSL.com
DV、OV、IV、およびEV証明書の違いは何ですか？ すべてが X.509証明書 暗号化、認証、および整合性を保証するために同様の方法を使用します。これらは、保護するIDについて含む情報が大幅に異なります。 証明書を分類する便利な方法は、証明書に含まれるサブジェクト情報を検証するために認証局（CA）が使用する方法によるものです。 ドメイン検証（DV） 検証の最低レベルであり、証明書を要求する人が、証明書が保護するドメインを制御していることを検証します。 組織検証（OV） の組織 (企業、非営利団体、または政府機関など) の身元を確認します。 証明書に記載されているサブジェクトと、組織が運営されている場所. 個別検証（IV） 個人の身元を確認する l証明書のサブジェクトとして記載されています。 これは、証明書を要求した人と同じ場合があります。 多くの場合、個人の住所も確認されます。 拡張検証
オレだよオレオレ認証局で証明書つくる - Qiita
ほうほう。.pemは鍵の種類ではなく暗号方式を表しているから、rsa方式で暗号化された秘密鍵も証明書も同じ拡張子になってる場合があるのか。 この辺は好みの問題なのか？そこはようわからん。 オレオレ認証局開設 世の中で見られるオレオレ証明書の作り方って、root認証局の証明書だった。 root認証局とは証明書の署名をしてくれているラスボス。ゾーマだよ。 ゾーマは子分であるバラモスが本物だって署名してくれている。 バラモスは子分である・・・と階層構造で署名がたどれる。 じゃぁゾーマを署名しているのは？ それはゾーマ自身が自分の証明書に署名している。これが自己証明書だ。 この自己証明書が本物だって登録がOSにある。 前提条件 今回はCentOS6のyumインストールで入ってるopensslでの記録。 コマンドパスとかファイルの場所とか違っても基本やることは一緒。 Macの場合は純正インストールの
SSLメールサーバ構築メモ Postfix + Dovecot【2023年版】
クラウドサービスの普及により自前でメールサーバを構築することは少なくなりましたが、自前で構築したメールサーバは他のシステムと連携しやすいなど自由度が高いのが魅力です。ただし、セキュリティの確保も自前でしっかり行わなければなりません。そこで今回は、SSL/TLSに対応したメールサーバを構築した時の手順をメモしておきました。
レンタルサーバーは格安のドメインキング
※ 料金は全て税込み表記です。 大切な独自ドメインは、安定した国内レンタルサーバーの「ドメインキング」にお任せください。月550円からの格安料金なのに、WordPressやデータベースなど50以上の人気機能を備えたクラウドベースのレンタルサーバーを自由に利用できます。ドメインをはじめて取得する初心者から、複数ドメインを低予算で管理・運用したい企業のシステム管理者まで、幅広いお客様に選ばれています。
AWS Certificate Managerでプライベート証明局を | Amazon Web Services
Amazon Web Services ブログ AWS Certificate Managerでプライベート証明局を 本日から、AWS Certificate Manager (ACM) には新機能のプライベート認証局 (CA) が追加されました。この新サービスを使用した場合、ACM はプライベート下位 CA として機能することになります。従来、顧客がプライベート証明書を必要とする場合、顧客には、保守と運用に高額の費用が必要になる、特殊なインフラストラクチャとセキュリティに関する専門知識が必要でした。ACM の既存の証明書機能のアドオンとなる ACM プライベート CA を使用すると、従量制課金が適用されるプライベート証明書のライフサイクルを容易にかつ安全に管理することができるようになります。これにより開発者は、いくつかの API 呼び出しを行うだけで、証明書をプロビジョニングすることがで
前方秘匿性 (forward secrecy) をもつウェブサイトの正しい設定方法
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景 WebサイトをHTTPS化する最も大きな理由は、インターネットの信頼性を維持することです。TLS技術の現状や、安全なHTTPS化に何が必要かを、ヤフー株式会社の大津繁樹氏が解説します。 「SEO対策のためには、WebサイトをHTTPS化しないといけない。」 —— そう聞かされて対応を迫られている技術者の方も多いのではないでしょうか？ 確かに、Googleは「HTTPSページが優先的にインデックスに登録されるようになります」と表明し、HTTPS化されたWebサイトが同社の検索結果で有利になると示唆しています。はたして、WebサイトのHTTPS化が必要な理由は、SEO対策だけなのでしょうか？ そして、それはGoogleという一社だけの意向で推奨されていることなのでしょうか？ こうした疑問に答
サーバ証明書を入れた時に一緒にやっておきたい暗号スイート設定｜つめあと的なやつ。
１.SSL Server Test 昨今のネット事情は、HTTPS必須の様相を呈してきました。 当サイトも無料ではありますがサーバ証明書を導入しています。しかし、ひょんな事からQUALYS SSL LABSのSSL Server Testというサイトを知りました。 このサイトは、簡単に言えば自分のサイトがどれだけのセキュリティレベルなのかがわかります。 試しに、VPSにサーバ証明書を入れただけの環境を入れてみると・・・ Σ（ﾟдﾟlll）し、C！！？ こらマズいと思い、きちんと対策をとりました。 ちなみに・・・オレっちの環境： バージョン ２.Ａ＋にするためのセキュリティ設定 まず、OpenSSLを最新化します。 yum update openssl openssl-devel ※2017年6月現在、OpenSSLのyumのリポジトリは1.0.1系しかありませんので、1.0.2系か1.1系
SSL/TLS 1.0 はいつまでに無効化しなければならないか？ | NTTデータ先端技術株式会社
Tweet はじめに 前回のコラムでは、PCI SSC が2015年12月18日に公開した、SSLおよび初期のTLSから安全なTLSへの移行期限の延長に関するプレスリリース[1]について、速報として概要を解説しました。今回は、プレスリリースと併せて公開された改訂内容について、より掘り下げて解説します。 改訂内容のおさらい まず、前回のプレスリリースと併せて公開された告示 [2], [3] で示された改訂内容をおさらいしましょう。 アクワイヤラ、プロセッサ、ゲートウェイ、およびサービスプロバイダを含む、処理業者および第三者の事業体すべては、2016年6月までに、TLS 1.1 以上のサービスを提供しなければならない すべての新しい実装は、PCI DSS v3.1に記載されている通り、TLS 1.1以上を有効にしなければならない すべての事業体は、2018年6月30日の発効日をもって、TLSの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to add custom certificate authority (CA) to nodejs
Adding Trusted Root Certificates to the Server
GitHub - FiloSottile/mkcert: A simple zero-config tool to make locally trusted development certificates with any names you'd like.
Securing a private IP address (https certificate)