並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 13 件 / 13件

新着順 人気順

X.509の検索結果1 - 13 件 / 13件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

X.509に関するエントリは13件あります。 securityセキュリティopenssl などが関連タグです。 人気エントリには 『図解 X.509 証明書 - Qiita』などがあります。
  • 図解 X.509 証明書 - Qiita

    はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書(1)』と『#5 X.509 証明書(2)』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名(前提知識) この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと

      図解 X.509 証明書 - Qiita
    • CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows - OpenSSL Blog

      Today we published an advisory about CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) and CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”). Please read the advisory for specific details about these CVEs and how they might impact you. This blog post will address some common questions that we expect to be asked about these CVEs. Q: The 3.0.7 release was announced as

      • OpenSSL Security Advisory : CA certificate check bypass with X509_V_FLAG_X509_STRICT (CVE-2021-3450)

        • OpenSSL Security Advisory [01 November 2022] - X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602)

          • Application Load Balancer can authenticate X.509 certificate based identities with Mutual TLS support

            Application Load Balancer (ALB) now supports Mutual TLS enabling you to authenticate clients while establishing TLS encrypted connections. Mutual TLS for ALB provides two different options for validating your X.509 client certificates. Using ALB’s Mutual TLS passthrough mode, ALB will send the entire client certificate chain to the target using HTTP headers, enabling you to implement relevant auth

              Application Load Balancer can authenticate X.509 certificate based identities with Mutual TLS support
            • 【小ネタ】AWS IoT(MQTT)へのアクセスでX.509証明書(秘密鍵)を使用しない場合もルート証明書は必須だった | DevelopersIO

              1 はじめに CX事業本部の平内(SIN)です。 今回、AWS IoT(MQTT)に、AccessKeyIDとSecretAccessKeyでアクセスして、少しハマってしまったので、覚書としてこれを記述しています。 結論から言うと、「X.509証明書と秘密鍵でアクセスしない場合でも、ルート証明書が必要」という事でした。ちなみに、この場合、MQTT over Websocket SigV4(ポート443)となります。 「当たり前だよ」って方には、未熟でほんとすいません。 2 X.509証明書ベース AWS IoTのコンソールからモノ(Thing)を作成すると、1-Clickで証明書を発行することができます。 また、オンボードメニューから作成した場合にダウンロードできる接続キットは、X.509証明書(秘密鍵)を使用するものになっています。 AWSIoTMQTTClientを使用して、X.509

                【小ネタ】AWS IoT(MQTT)へのアクセスでX.509証明書(秘密鍵)を使用しない場合もルート証明書は必須だった | DevelopersIO
              • X.509クライアント証明書で接続しているデバイスでAWS Secrets Managerを使ってみました | DevelopersIO

                1 はじめに CX事業本部の平内(SIN)です。 IoT Coreに接続されるデバイスは、証明書を使用して接続されているものが多いと思います。(※1) 今回は、そのようなデバイスで、「シークレットな情報」を扱う場面をイメージし、AWS Secrets Managerを使用する要領を確認してみました。 なお、AWS Secrets Managerでは、主要な用途として、データベースの認証情報(※2)がありますが、すいません、これには触れておらず、その他のシークレットとして、JSONテキストの保存のみを使っています。 (※1) X.509クライアント証明書による認証では、証明書数の上限もなく、また、事前登録無しで利用できる仕組み(JITR、JITP、Fleet Provisioning)も用意されていることから、 他の認証方法(Amazon Cognito、AWS IAM、カスタム認証)に比べ

                  X.509クライアント証明書で接続しているデバイスでAWS Secrets Managerを使ってみました | DevelopersIO
                • CVE-2022-3786 and CVE-2022-3602: X.509 Email address buffer overflows

                  CVE-2022-3786 and CVE-2022-3602: X.509 Email address buffer overflows Nov 1, 2022 Today we published an advisory about CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) and CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”). Please read the advisory for specific details about these CVEs and how they might impact you. This blog post will address some common questions t

                  • x.509属性証明書とVerifiable Credential

                    こんにちは。CTO室長の浅野(@masakz5)です。 SSIのVerifiable Credentialのについて見聞きしたとき、昔からPKIやx.509証明書に関わっている方々の中には「属性証明書(Attribute Certificate)」のことを思い出される方も多いかもしれません。 今回のブログでは、この属性証明書とVerifiable Credential(VC)を比較してみたいと思います。 属性証明書とは何か 属性証明書(Attribute Certificate)とは、証明書の発行対象の属性情報を公開鍵の証明書とは別のx.509証明書として発行するという考え方で、2002年にRFC3281としてRFCとなり、2010年にこれを改定する形でRFC5755となっています。 以前のブログ記事でも書いたように、一般的にx.509証明書と呼ばれるものは、公開鍵(=対となる秘密鍵)とそ

                      x.509属性証明書とVerifiable Credential
                    • Illustrated X.509 Certificate

                      IntroductionThis article explains X.509 certificate. 1. Digital Signature (Prior Knowledge)To read this article, knowledge about digital signature is needed. That is, this article assumes that you understand “By verifying signature with the public key which is paired with the private key used to generate the signature, you can confirm that the target data has been surely signed by the owner of the

                        Illustrated X.509 Certificate
                      • PEM, DER, CRT, and CER: X.509 Encodings and Conversions - SSL.com

                        You may have seen digital certificate files with a variety of filename extensions, such as .crt, .cer, .pem, or .der. These extensions generally map to two major encoding schemes for X.509 certificates and keys: PEM (Base64 ASCII), and DER (binary). However, there is some overlap and other extensions are used, so you can’t always tell what kind of file you are working with just from looking at the

                        • GitHub - smallstep/cli: 🧰 A zero trust swiss army knife for working with X509, OAuth, JWT, OATH OTP, etc.

                          Step CLI's command groups illustrate its wide-ranging uses: step certificate: Work with X.509 (TLS/HTTPS) certificates. Create, revoke, validate, lint, and bundle X.509 certificates. Install (and remove) X.509 certificates into your system's (and browser's) trust store. Validate certificate deployment and renewal status for automation Create key pairs (RSA, ECDSA, EdDSA) and certificate signing re

                            GitHub - smallstep/cli: 🧰 A zero trust swiss army knife for working with X509, OAuth, JWT, OATH OTP, etc.
                          • JWTの署名検証で使う公開鍵をX.509証明書で管理する - Carpe Diem

                            概要 JWTをアクセストークンとして利用する場合、署名(秘密鍵)は認証サーバで、署名検証(公開鍵)はリソースサーバで行うのが良いです。 そのため認証サーバは公開鍵をリソースサーバに公開する必要があります。 Googleなどの大規模サービスを見ると、生の公開鍵を公開しているのではなくX.509証明書の形で公開されています。 これは 公開鍵の有効期間が設定できる 公開鍵が改ざんされていない事が分かる なりすましによる公開鍵でないことが分かる 秘密鍵が漏洩した時に失効ができる といったデジタル署名のメリットを享受できるようにと考えられます。 { "4e00e8fe5f2c88cf0c7044f307f7e739788e4f1e": "-----BEGIN CERTIFICATE-----\nMIIDHDCCAgSgAwIBAgIILnkHftPtFMYwDQYJKoZIhvcNAQEFBQAwM

                              JWTの署名検証で使う公開鍵をX.509証明書で管理する - Carpe Diem
                            1

                            新着記事