Go encoding/pem.Decode 为什么第二段证书找不到

我在处理证书链配置时遇到过一个很像“第二张证书丢了”的问题：第一段 PEM 可以读出来，第二段却始终是 nil。真正的关键通常不在证书内容，而在 encoding/pem.Decode 的返回值。它每次只找一个 PEM 块，同时把尚未消费的字节放进 rest；要读取下一段，必须把 rest 再交给下一次 Decode。

官方文档：https://pkg.go.dev/encoding/pem#Decode

第二段 PEM 找不到时，先检查是否循环使用了 rest，再检查 -----BEGIN ...----- 是否从行首开始、-----END ...----- 是否在行尾结束。pem.Decode 只负责找出 PEM 块，不负责验证证书链。

你调用Go标准库的`encoding/pem.Decode`方法读取多段证书文件只返回第一段、找不到第二段，最常见的原因是你只调用了一次Decode就停止读取，或者第二段证书的边界格式不符合PEM规范导致解析失败。

pem包的Decode函数单次调用只会从输入数据里提取第一个合法的PEM块，想要拿到所有证书段需要循环调用Decode直到返回nil为止。

返回值先分清：block 和 rest 不是同一个东西

Decode 的签名是 func Decode(data []byte) (p *Block, rest []byte)。block 是本次找到的第一个块，rest 是它结束位置之后仍未处理的输入。如果输入里没有 PEM 数据，block 为 nil，但 rest 会保留整段输入。

package main

import (
    "encoding/pem"
    "fmt"
)

func main() {
    data := []byte("说明文字\n-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n")

    // Decode 只消费当前找到的第一个 PEM 块，rest 仍指向未处理的输入。
    block, rest := pem.Decode(data)
    if block == nil {
        // nil 只表示没有找到格式完整的 PEM 块，不等于 rest 为空。
        fmt.Printf("没有找到 PEM，剩余输入长度：%d\\n", len(rest))
        return
    }

    // Type 用于判断块的业务类型，Bytes 才是解码后的原始内容。
    fmt.Printf("类型：%s，内容字节：%d，剩余输入：%d\\n", block.Type, len(block.Bytes), len(rest))
}

这里不要把 rest 丢掉。它可能包含第二段 PEM，也可能只是 PEM 后面的普通文本。两种情况都需要由调用方决定如何处理。

连续读取多段 PEM：每次都把 rest 交给下一次 Decode

多个证书或密钥连续拼接时，最稳妥的写法是维护一个待处理切片。每次成功取到一个块后，把 rest 替换为下一轮输入；当 block == nil 时停止。这样不会把第一轮的原始输入重复传入，也不会误把普通前缀当成第二个块。

package main

import (
    "bytes"
    "encoding/pem"
    "fmt"
)

func decodeAll(data []byte) ([]*pem.Block, []byte) {
    var blocks []*pem.Block
    rest := data

    for len(bytes.TrimSpace(rest)) > 0 {
        // 每一轮只从上一轮的 rest 中寻找下一个 PEM 块。
        block, next := pem.Decode(rest)
        if block == nil {
            // 找不到完整块时保留原始剩余内容，便于调用方记录或处理前缀。
            return blocks, rest
        }
        blocks = append(blocks, block)
        // next 可能还包含普通文本或下一段 PEM，不能直接丢弃。
        rest = next
    }

    return blocks, rest
}

func main() {
    blocks, rest := decodeAll([]byte("...多个 PEM 块..."))
    fmt.Printf("块数量：%d，未解析字节：%d\\n", len(blocks), len(rest))
}

这段代码的一个重要取舍是：遇到非 PEM 内容后直接返回，而不是无条件丢弃它。生产代码可以根据输入协议决定是否允许注释、空白或尾部元数据；如果协议不允许，就应把 rest 记录为格式错误。

为什么看起来“第二段找不到”：三个常见边界

现象	真正要检查的点	处理方式
第一段成功，第二段为 nil	是否把第一轮的 rest 传入下一轮	循环更新待处理切片
输入里有 BEGIN 但 block 为 nil	BEGIN 是否位于行首、END 是否位于行尾	修正换行和拼接方式
block 成功但证书不可用	这是 DER 内容或证书校验问题	再调用 x509.ParseCertificate 或 Verify

文档要求 PEM 块从一行开头开始，并在一行结尾结束。因此把两段内容拼到同一行、或在网络传输中去掉换行，都会让问题看起来像“第二段证书消失”。

把 PEM 解码和证书校验分开

pem.Decode 成功只说明找到了一个可解析的 PEM 外壳，并不说明 block.Bytes 一定是目标证书，更不代表证书链可信。若块类型是 CERTIFICATE，可以继续交给 x509.ParseCertificate；如果要判断签发关系或主机名，还要使用对应的 X.509 校验 API。

package main

import (
    "crypto/x509"
    "encoding/pem"
    "fmt"
)

func parseCertificate(data []byte) (*x509.Certificate, []byte, error) {
    // 先完成 PEM 层解析，再把 Bytes 交给 X.509 层。
    block, rest := pem.Decode(data)
    if block == nil {
        return nil, rest, fmt.Errorf("没有找到 PEM 块")
    }
    if block.Type != "CERTIFICATE" {
        return nil, rest, fmt.Errorf("块类型不是 CERTIFICATE：%s", block.Type)
    }

    // ParseCertificate 只解析 DER 结构，不代替完整的信任链验证。
    cert, err := x509.ParseCertificate(block.Bytes)
    if err != nil {
        return nil, rest, fmt.Errorf("解析证书 DER 失败：%w", err)
    }
    return cert, rest, nil
}

排查顺序可以固定下来

1. 打印或统计第一轮 block 和 rest 的长度，不要只打印 block.Type。
2. 确认第二轮输入确实是上一轮返回的 rest，而不是原始字节。
3. 检查每个 BEGIN/END 标记的换行位置，并保留输入中的换行。
4. 确认块类型后再进入 X.509、PKCS#8 或私钥解析，不把不同层级的错误混在一起。

掌握这条边界后，“第二段证书找不到”通常能很快缩小为两类问题：调用方没有继续消费 rest，或者输入不满足 PEM 的行边界。只有在确实拿到目标块以后，才值得继续排查 DER 结构和证书信任关系。

相关问题

pem.Decode 返回 nil 时 rest 应该怎么处理？

先保留它。官方语义是没有找到 PEM 时返回 nil 和完整输入，调用方可以据此记录格式错误、处理前缀或结束解析。

读取第二段 PEM 是否要重新传入原始字节？

不需要。第二轮应传入上一轮返回的 rest，否则可能重复读到第一段，或让循环无法前进。

pem.Decode 能判断证书是否可信么？

不能。它只负责 PEM 外壳的查找与解码；证书结构解析、链验证和主机名匹配属于后续 X.509 API 的职责。