Problem beim Bereitstellen von ExtendedKeyUsage-Informationen für CSR während des Golang-Builds

Während der CSR-Generierung in Golang gab es ein Problem bei der Bereitstellung von Informationen für ExtendedKeyUsage. Dieses Problem kann die Richtigkeit und Gültigkeit der generierten CSR beeinträchtigen. ExtendedKeyUsage ist Teil der Zertifikatserweiterung und wird verwendet, um den Zweck der Verwendung des Zertifikats anzugeben. Durch die Bereitstellung korrekter ExtendedKeyUsage-Informationen an den CSR kann die Verfügbarkeit und Sicherheit des Zertifikats in bestimmten Szenarien sichergestellt werden. In Golang tritt jedoch manchmal das Problem auf, dass ExtendedKeyUsage-Informationen beim Generieren von CSR nicht korrekt bereitgestellt werden können. Der PHP-Editor Xigua wird in diesem Artikel die Ursachen und Lösungen für dieses Problem ausführlich vorstellen, um den Lesern dabei zu helfen, ähnliche Probleme zu lösen und erfolgreich eine CSR zu erstellen, die den Anforderungen entspricht.

Frageninhalt

Ich bin auf ein seltsames Problem gestoßen. Ich schreibe ein kleines golang-Tool, das csr basierend auf einigen vom Benutzer bereitgestellten Eingaben generiert. Ich habe mein Ziel größtenteils erreicht, hatte aber Probleme mit der erweiterten Tastennutzung. Einfach ausgedrückt: Es funktioniert nicht.

asn1-Marshalling-Code für einige x509-Felder:

var oidemailaddress = asn1.objectidentifier{1, 2, 840, 113549, 1, 9, 1}
    var oidextensionkeyusage = asn1.objectidentifier{2, 5, 29, 15}
    var oidextensionextendedkeyusage = asn1.objectidentifier{2, 5, 29, 37}

    asn1keyusagedigsig, err := asn1.marshal(asn1.bitstring{
        bytes:     []byte{byte(x509.keyusagedigitalsignature)},
        bitlength: 8,
    })
    asn1keyusagedatenc, err := asn1.marshal(asn1.bitstring{
        bytes:     []byte{byte(x509.keyusagedataencipherment)},
        bitlength: 8,
    })
    asn1keyusagecauth, err := asn1.marshal(asn1.bitstring{
        bytes:     []byte{byte(x509.extkeyusageclientauth)},
        bitlength: 8,
    })

    if err != nil {
        error.fatalf("can't serialize extended key usage %s", err)
    }

Dann habe ich eine Vorlage erstellt und die csr erfolgreich generiert und gespeichert, fast:

template := x509.certificaterequest{
        rawsubject:         asn1subj,
        emailaddresses:     []string{emailaddress},
        signaturealgorithm: _sigalg,
        extraextensions: []pkix.extension{
            {
                id: oidextensionextendedkeyusage,
                value: asn1keyusagecauth,
            },
            {
                id:       oidextensionkeyusage,
                critical: true,
                value:    asn1keyusagedatenc,
            },
            {
                id:       oidextensionkeyusage,
                critical: true,
                value:    asn1keyusagedigsig,
            },
        },
    }

    csrbytes, _ := x509.createcertificaterequest(rand.reader, &template, privatekey)

and here is an openssl req -in my_output.csr -text -noout

******
         asn1 oid: prime256v1
                nist curve: p-256
        attributes:
        requested extensions:
            x509v3 subject alternative name: 
                email:[email protected]
            x509v3 extended key usage: 
                ....
            x509v3 key usage: critical
                key agreement
            x509v3 key usage: critical
                encipher only
    signature algorithm: ecdsa-with-sha256

******

Meine erweiterte Schlüsselverwendung ist leer, obwohl es sich um die Clientauthentifizierung handeln sollte. Was habe ich falsch gemacht?

Ich freue mich auf Folgendes:

X509v3 Extended Key Usage: ClientAuthentication

Ich sehe leere Felder. Ich habe versucht, einen anderen Satz von Bytes aus einem anderen OID zu verwenden, aber immer noch keine Ergebnisse. Es ist, als ob das Feld extendedkeyusage nicht zulässt, dass etwas geschrieben wird (obwohl es sollte)

Bei Import:

Version: go1.19.3 darwin/amd64

Workaround

Ich denke, das Problem liegt beim Drucken der Daten. Die Schlüssel/Werte sind tatsächlich in den Daten vorhanden.

Aus dem Code:

var oidextensionextendedkeyusage = asn1.objectidentifier{2, 5, 29, 37}

asn1keyusagecauth, err := asn1.marshal(asn1.bitstring{
    bytes:     []byte{byte(x509.extkeyusageclientauth)},
    bitlength: 8,
})

extraextensions: []pkix.extension{
    {
        id: oidextensionextendedkeyusage,
        //critical: true,
        value: asn1keyusagecauth,
        //value: {2, 5, 29, 15},
    },

oidextensionextendedkeyusage ist asn.1 oid 2.5.29.37, was bei Codierung mit dem Encoder „55 1d 25“ ist

Sie können es online kodieren, um zu sehen, welche Binärdatei es generiert (z. B. https://www.php.cn/link/8e08227323cd829e449559bb381484b7)

asn1keyusagecauth-Wert ist 2 (Konstante definiert in x509.go), was „00 02“ ist, wenn es mit dem Encoder in die asn.1-Bitzeichenfolge codiert wird (die erste 00 ist die Anzahl der Füllbits (keine), 02 ist die Füllziffern). ) Wert 2)

Erhalten Sie nun den Base64-Wert der Zertifikatsanforderung und dekodieren Sie ihn mit dem asn.1-Der-Decoder (z. B.: https://asn1.io/asn1playground)

miibtzccav0caqawgzwxczajbgnvbaytakfvmq8wdqydvqqiewztewruzxkxdzan bgnvbactbln5zg5letetmbega1uechmkc210aensawvuddelmakga1uecxmcsvqx jtajbgnvbamthhntdggtq2xpzw50lvk4cdg1bk1psvnzmgliz0exijagbgkqhkig 9w0bcqeme3ntdghjbgllbnrac210ac5jb20wwtatbgcqhkjopqibbggqhkjopqmb bwncaar4riguoxsyxdaml9f9e2grjumuk8q0jilotb2kadmbz1rocedszuuxkqcr 0vud2aw3vidph1ar4hkqwkm43hxqof4wxayjkozihvcnaqkomu8wttaebgnvhree fzavgrnzbxroy2xpzw50qhntdgguy29tmasga1udjqqeawiiaajaobgnvhq8baf8e bamcaagwdgydvr0paqh/ba​​qdagabmaogccqgsm49bamca0gameuciqdtbj+0atjy f1gy8am2mv7/x3tsebmmvdszkw8l6rvseqigmih8co9nkp0axdmgp9x4kvjjzk9x rw3roydt89d73oa=

try the full power of oss' asn-1step by downloading a free trial

oss nokalva tlv print utility  version 8.6.1
copyright (c) 1997-2022 oss nokalva, inc.  all rights reserved.


30 8201b7(439)
  30 82015d(349)
    02 01 00
    30 819c(156)
      31 0b
        30 09
          06 03 550406
          13 02 4155
      31 0f
        30 0d
          06 03 550408
          13 06 5379646e6579
      31 0f
        30 0d
          06 03 550407
          13 06 5379646e6579
      31 13
        30 11
          06 03 55040a
          13 0a 736d7468436c69656e74
      31 0b
        30 09
          06 03 55040b
          13 02 4954
      31 25
        30 23
          06 03 550403
          13 1c 736d74682d436c69656e742d59387038356e4d694953733069486741
      31 22
        30 20
          06 09 2a864886f70d010901
          0c 13 736d7468636c69656e7440736d74682e636f6d
    30 59
      30 13
        06 07 2a8648ce3d0201
        06 08 2a8648ce3d030107
      03 42 000478ac88143b14b25dd68c2fd17d7b68118ee3142bc4348e29684dbda401d9...
    a0 5e
      30 5c
        06 09 2a864886f70d01090e
        31 4f
          30 4d
            30 1e
              06 03 551d11
              04 17 30158113736d7468636c69656e7440736d74682e636f6d
            30 0b -- here it is!
              06 03 551d25
              04 04 03020002
            30 0e
              06 03 551d0f
              01 01 ff
              04 04 03020008
            30 0e
              06 03 551d0f
              01 01 ff
              04 04 03020001
  30 0a
    06 08 2a8648ce3d040302
  03 48 003045022100d3063fb402d8f2175198f0033632feff5f7b6c11b98c55db332b0f25...


results
to get more details, please provide/compile a schema for your data.

Scrollen Sie die Ausgabe oben nach unten, bis Sie sie hier finden!

Ihr Schlüssel/Wert ist:

30 0B    -- a SEQUENCE of 11 bytes
    06 03 551D25   -- an item of 3 bytes (551D25 ... OidExtensionExtendedKeyUsage)
    04 04 03020002 --  an item of 4 bytes (03 02 0002 ... an item of 2 bytes 0002 ... asn1KeyUsageCAuth)

Ich würde die CSR gerne gemäß der ASN.1-Spezifikation dekodieren ... aber ich kann sie nicht finden :(

Das obige ist der detaillierte Inhalt vonProblem beim Bereitstellen von ExtendedKeyUsage-Informationen für CSR während des Golang-Builds. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!