I get the idea of this type, but for me at least I always end up casting my Array<Uint8Array> to [Uint8Array, ...Uint8Array[]] which is rather annoying. If you see the added benefit for the type we can keep it, but it annoys me more in general then it helps.

For me it ensures the user of this library needs to think about the length of the chain. If you pass it like this:

{
 certificates: [leafCertificates]
}

It will not complain

But if you pass it like this:

{
  certificates: certificateChain
}

it would require the user to have checked themselves that they have at least one cert. So i like it since it either requires a cast (excplicit) or enforce you to adhrere to the type (explicit)

I get the type, but checking certificateChain.length > 1 does not transform the type in an "at-least-one-member" type. The example below does not work and still requires casting

function y(arr: [string, ...string[]]) {
    console.log(arr)
}

 const x= ['a']

if(x.length < 1) {
    throw new Error('a')
}

y(x) // <-- ERROR

no agreed, you have to write it in a typescript compatible way. I like this pattern, as it requires your runtime validation to match your compile time validation

function isNonEmptyArray<T extends any>(array: T[]): array is [T, ...T[]] {
  return array.length > 1
}

function assertNonEmptyArray<T extends any>(array: T[]): asserts array is [T, ...T[]] {
  if (array.length === 0) {
  throw new Error('Expected array to at least contain one entry')
}
}

function y(arr: [string, ...string[]]) {
    console.log(arr)
}

 
 const x= ['a']

if (isNonEmptyArray(x)) {
  y(x) // <-- SUCCESS
}

assertNonEmptyArray(x)
y(x) // <-- SUCCESS

I can change it, it's fine