asn1: syntax error: sequence truncated

[zeph]

$ certigo verify --name=aaaa.xxx.kube --ca=ca.crt xxx.xxx.tld.cer 
Certificate has OCSP extension, but was unable to check status:
	asn1: syntax error: sequence truncated

Found 1 valid certificate chain(s):
[0] CN=xxx.xxx.tld	=> CN=XXX-Device-CA

did we step on this? golang/go#12910

...shall be solved by:

• https://go-review.googlesource.com/c/go/+/17550/1/src/crypto/x509/x509.go#1072

ideas?

[mcpherrinm]

The OCSP support in certigo isn't very robust.

I don't think it's the issue you mentioned, though. That was fixed years ago.

Can you share the certificate which produced the error, or how it was generated?

[zeph]

@mcpherrinm I created it with xca (the CSR)
...it got signed and issued by colleagues (probably a M$ product)

I can give you the OCSP exchanges, please don't post the readable format here

$ openssl ocsp -reqin request.ocsp -respin response.ocsp -text
[...]
Response verify OK

*** they belong to a customer of mine, I don't want em to be indexed

$ cat request.ocsp |base64 
MHkwdzBQME4wTDAJBgUrDgMCGgUABBT5Alm2ciDV6VypiG27ch5J81hbkwQUIjrbGQ/vC5blbunb
VwPshgxnwAACEyQAAEg22AgY5ZVz1fMAAAAASDaiIzAhMB8GCSsGAQUFBzABAgQSBBD74b8xz8cX
KL4Q57/l9vsE

$ cat response.ocsp |base64 
MIIGcAoBAKCCBmkwggZlBgkrBgEFBQcwAQEEggZWMIIGUjCB6qIWBBQZcl4RRwAYEtpO9819CGM5
3fxsgxgPMjAxOTA5MTAxMDM1NTdaMIGZMIGWMEwwCQYFKw4DAhoFAAQU+QJZtnIg1elcqYhtu3Ie
SfNYW5MEFCI62xkP7wuW5W7p21cD7IYMZ8AAAhMkAABINtgIGOWVc9XzAAAAAEg2gAAYDzIwMTkw
OTA4MTQ1MDAyWqARGA8yMDE5MDkxNjAzMTAwMlqhIDAeMBwGCSsGAQQBgjcVBAQPFw0xOTA5MTUx
NTAwMDJaoSMwITAfBgkrBgEFBQcwAQIEEgQQ++G/Mc/HFyi+EOe/5fb7BDANBgkqhkiG9w0BAQUF
AAOCAQEAJLVOTGg0TV6IPqRamZYxyLqq6CmSmUZKgc23UQmFdmByJD2fyUMzi1xnAY7WA/VefEvr
AvutfPYZOkOOsAC4PeSk7LlKsZzrsJkG+pIdt0EwfD+gt6rEPySH97YKFdNR5SWM85yE5/uofJ2W
WwNro72wB+9SkcaE+maswWmHRvtUh6MjHhSmwRPPb/vk89GCooY/uk7dLDOZyi5CSn3hF6Re07lQ
x3vVD/S+PEr9oINhxJ8axd2stK+O4zsNmV6m1YO1kcRHjr+ieRc6oTVKEi973WYtZTfO+P5xqw3Q
J1t9RC18FGccjzzdo9PzZIpgRnuDgOvgCBVG2FO4173MI6CCBE0wggRJMIIERTCCAy2gAwIBAgIT
JAAAQQCfUJPKs1m2zgAAAABBADANBgkqhkiG9w0BAQsFADBWMRIwEAYKCZImiZPyLGQBGRYCREUx
EzARBgoJkiaJk/IsZAEZFgNBVFUxEzARBgoJkiaJk/IsZAEZFgNBRFMxFjAUBgNVBAMMDUFUVS1E
ZXZpY2UtQ0EwHhcNMTkwNTAyMDgwMzUyWhcNMTkxMDI5MDgwMzUyWjBXMRIwEAYKCZImiZPyLGQB
GRYCREUxEzARBgoJkiaJk/IsZAEZFgNBVFUxEzARBgoJkiaJk/IsZAEZFgNBRFMxFzAVBgNVBAMM
Dk9DU1AgRGV2aWNlLUNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA39HAWn1PzMzs
EFxiLShQ7Ua7gVffu7yY9jArJ5ZsZZZEZ34K6rMLeWmpGAG/AyAELZwg4GP0pIui/z0kqOGhbUuF
J48KskZYfAfFhjjlLFbPMZi2DInJxy2EmTBUDke9QvldK2Y+je4v3rlj1u9FCSVM4w27uiAHLukN
pIJoe93SPiABGOMPNuYd0lQaMWWK7zbC5qO1faYbdSQYr32V2+KFvB+B+aKbyKivWvkzKfshFonU
e9B3NgY4ooXMMIoJ8VuV/88F2WPsvgiqbsBJt/r13P2ahaHGQ/LOewxkiZiuOxwsW12txKsuz4bw
4Q5HOUO3IaCUl+9vqyVoZQZfnQIDAQABo4IBCTCCAQUwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEF
BQcDCTATBgNVHSUEDDAKBggrBgEFBQcDCTAPBgkrBgEFBQcwAQUEAgUAMB0GA1UdDgQWBBQZcl4R
RwAYEtpO9819CGM53fxsgzAOBgNVHQ8BAf8EBAMCB4AwMQYDVR0RBCowKIISZW5jcnlwdGlvbjEu
YXR1LmRlghJlbmNyeXB0aW9uMi5hdHUuZGUwHwYDVR0jBBgwFoAUIjrbGQ/vC5blbunbVwPshgxn
wAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIh8esZYeB60CRnSyF15Qlg4KEDIFJgvyHHoOR
smYCAWQCAQIwDQYJKoZIhvcNAQELBQADggEBAChEYr8HDHsX/IEirVMxPTVaWBYgLZxMilrkBTPn
vfVxFjVOtrKtu3+yWi1OJa81HyMzS8UMn4db9ZQY1w3SLaASoTdSj0NoXOOGrqRhWIwCWReR4z/d
1UBGy/0AuEwneYuLgdlFwu6VLVvUGBHZgbVD9wk3ADStaQmzdRMWu2RX17Vr9qBT9Tl4R9LSwUNe
KPDF17QT8eGZ1aa948HgPVkufhVQDwoTByFVDHulOvv0prKG5iopQk6Fh9rizUUbQ0xyTrj30jBl
fuftoQ0otAfFxDVkVzCww0lnCH6+jAZlYEL4l70ph55JN07P3xmTr5hCr+9GITe+cJGJOGodKJ8=

[siebenmann]

I have seen this error when a locally generated TLS certificate lacked OCSP information at all. Debugging the situation with my TLS certificate, lib/ocsp.go's fetchOCSP() finds that issuer.OCSPServer is empty and falls through to return nil, nil, and nil (since lastError is still unset) to its caller, lib/ocsp.go'scheckOCSP(). Unfortunately, checkOCSP() doesn't notice that encoded is nil, hands it to ocsp.ParseResponse(), and not unreasonably gets this error back.

Based on the code that calls checkOCSP() in lib/verify.go, it seems that the simplest solution is to make checkOCSP() return skippedRevocationCheck in this case. It might also work to return nil, nil, but that's somewhat different from what the code does now.

[jdtw]

Should be fixed now.