[sebxt]

crl.NewCRLFromFile and the gencrl API handler ignore the result of big.Int.SetString, so a serial that does not parse as a decimal integer still ends up in the CRL, with a value of 0 or the leading digits of the input. For example, a serial list of 1, 2, 0x03, 28:35:69:0a yields CRL entries 1, 0, 0 and 28. The certificates that were meant to be revoked are not, and no error is shown. NewCRLFromFile also checks for blank lines with a trimmed copy of the line but parses the untrimmed one, so a leading or trailing space is enough to trigger this.

This change trims each serial before parsing and returns an error when SetString fails: a plain error from NewCRLFromFile, and a 400 response from the API handler. Valid decimal input is handled as before. Accepting hex serials (#979) is left for a separate change.

Testing: added TestNewCRLFromFileCRLFAndWhitespace (CRLF line endings and surrounding spaces give the right serials) and TestNewCRLFromFileInvalidSerial (an invalid line returns an error) in crl/crl_test.go, and TestCRLInvalidSerial (expects a 400 for an invalid serial) in api/gencrl/gencrl_test.go. All three fail on master and pass with this change. go test ./crl/ ./api/gencrl/ ./cli/gencrl/ passes.

Fixes #1460