How do you create and use CAs and certificate using cross-signing?

• Let me start by saying, that a bit of guesswork is included in my answer. My best guess is that you issued 2 leaf certs and that one cert's issuer points to the other and the other way around, causing the loop. I didn't try to reproduce your issue myself, but did play with cross signing. The LE site (Cross Signing by LE) and your hints, made me succeed in issuing and using certificates with cross-signing. My objective was not CA root resilience but CA root roll-over. If your role is CA, it's basically not much different from what you tried to achieve. Critical factors are:
  
• The Subject field must be identical (see above too)
  
• The keys must be identical (see above too)
  
• The certs must have a different issuer and 1 can be self-signed, like my application
  

Partly like the LE link, I created a Intermediate cert with cross-signing and one new root cert. A permanent Intermediate cert (PATHLEN:0) is signed by one of the 2 cross signed certs, unimportant which one, because the subject and keys are identical. Hint: reuse the CSR of the to-be cross certs for both, so the Subject can't be wrong. On the cross signed (temp.) Intermediate cert, I set the PATHLEN to 1 (can't be 0!) To make it very clear:

• Path 1 (old root): Leaf cert, perm. Intermediate cert, temp. Intermediate cert, 'old' root cert
  
• Path 2 (new root): Leaf cert, perm. Intermediate cert, 'new' root cert
  

You can play with SAN and start/end dates what you like. The Intermediate cert (temp or roll-over) in the 'old' root path has 5 years validity, the 'new' root 10 years. After importing the 'new' root cert, the shorter (4 → 3) path was immediately used by Firefox. In my case you need to load 3 certificates on the web-server: leaf cert, perm. intermediate cert, temp. intermediate ('old' root/temp/roll-over) cert. OpenSSL didn't disappoint me to test the leaf cert for a valid path. I used OpenSSL's verify tool with CAfile for the root in the path and untrusted for the used Intermediate cert(s). Both paths to the old and the new root could be verified this way. As an end-user (non-CA), if you want to have resilience, it should work with 1 CSR to get (order) leaf certs from 2 CAs and load your web-server with those 2 certs chained with the Intermediate cert from the issuing CA. So 4 certs in total.

Understanding Under-signing

 Cross-signing is simply when multiple valid paths exist between a root certificate and a node certificate. This can be advantageous for a number of reasons. Sometimes, a certificate in the chain expires. While it would be nice if every piece of software was frequently updated and shipped an up-to-date copy of the root CA store, this is not the case in the real world. Many devices, for a number of reasons, are not subject to regular updates. Strategically cross-signing intermediate certificates from an older (therefore more likely to be present on the larger subset of devices in the wild) root certificate, “buys some time”.