How to provide CA certs for ListenAndServeTLS function

It says that in the docs

"ListenAndServeTLS acts identically to ListenAndServe, except that it expects HTTPS connections. Additionally, files containing a certificate and matching private key for the server must be provided. If the certificate is signed by a certificate authority, the certFile should be the concatenation of the server's certificate, any intermediates, and the CA's certificate."

Yet i can barely understand what concatenation and intermediates actually mean.
Could anyone please kindly give me an example? Thanks in advance.

Btw, i don't wanna load CA cert in the tls.Config, which works well definitely;)

The previous answer didn't resolve any problem. The easiest way is uploading your cert (your certificate, not your private key, for obvious reason!) to certificatechain.io.

Another alternative is simple request the ca-bundle to your CA, then you will concatenate as follows:

-----BEGIN CERTIFICATE-----
YOUR CERT
YOUR CERT
YOUR CERT
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
SOME INTERMEDIATE CERT
SOME INTERMEDIATE CERT
SOME INTERMEDIATE CERT
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
ANOTHER INTERMEDIATE CERT
ANOTHER INTERMEDIATE CERT
ANOTHER INTERMEDIATE CERT
ANOTHER INTERMEDIATE CERT
-----END CERTIFICATE-----

Note that the order matters. Once you have this file in hands you can use the "new certificate" in the ServeAndListenTLS().

That's a minor detail, just ignore it and add your cert.pem and key.pem file like the docs say. It's talking about how you can "chain" (concatenate) certificates together to transfer trust from the root certificate to intermediate certificates. All of this is details of how PKI works, and you don't have to worry as long as you aren't messing with the cert and key files.

You see, the way your browser knows PayPal is actually PayPal is by verifying that PayPal's certificate was signed by a root certificate trusted by your computer. In this case, Symantec signed the certificate.

Intermediate certificate authorities can be made. For example, the most secure CAs don't actually hook the server with the root certificate to the internet; everything is signed with intermediate certificate authorities that have themselves signed by the root certificate. If an intermediate CA got hacked, Symantec could then revoke all the certificates signed by that CA a lot easier than getting a new public key setup.

Your browser can trust PayPal because it was signed by an intermediate CA of Symantec. The intermediate CA's certificate was signed by the root CA of Symantec.