Interrupts happening during a critical section should be triggered properly when that section has ended.
The only problem might be that the CAN controller might lose messages if the section takes to long to execute (but the same problem occurs when ISR execution as such takes too long).
You may play around with the interrupt priorities to avoid the need for critical sections. When CAN has got the highest priority (lowest number) no message will be lost.
Actually, I would like to store the messages in a list which will be checked and changed in a main loop. I would like to keep it real time.
Data transmission is (even at high rates) comparatively slow compared to the CPU's speed.
Since the implementation of CAN is done in real hardware, this will keep on running when interrupts are disabled for a short time. Afaik there will an error-flag raised on an RX overrun, so that you have the chance to at least "see" a transmit error.
Storing messages in a list and handling in the main-loop does generally not conflict with other interrupt driven parts of your project.