Seu certificado de site (+ chave privada) deve ser tratado como qualquer certificado de site. Se alguém conseguisse obter a chave privada, seria capaz de se passar por seu site. Há pouca diferença no modo como você deve confiar no serviço de hospedagem para um certificado emitido por uma autoridade de certificação comercial.
Os riscos aqui são mitigados pelo fato de que, desde que você criou sua própria autoridade de certificação, poucas pessoas confiarão nessa autoridade por padrão. É um risco efetivamente limitado àqueles que optaram por confiar em sua CA.
O mesmo se aplica à chave privada da CA. Alguém que consiga sua chave privada pode emitir qualquer certificado.
Os maiores problemas vêm do fato de que as interfaces de usuário tendem a tratar todas as CAs confiáveis igualmente (a menos que EV certs), ou de forma muito semelhante, se o usuário não prestar atenção. Como resultado, se um invasor (a) possuísse a chave privada de sua CA e (b) conhecesse um usuário que confia nesse certificado da CA, ele poderia criar um certificado válido para qualquer site que desejasse.
Sua avaliação de risco deve levar em consideração quem optará por confiar nessa CA interna. As CAs comerciais tendem a ter políticas rígidas em relação à proteção de suas chaves privadas (geralmente, armazenamento não-extraível em cartões inteligentes ou similares): isso geralmente é um requisito para ser aprovado para inclusão na maioria dos navegadores.
Mais especificamente sobre "outras informações". Pode ser importante, ao projetar uma CA, ter uma política sobre quais atributos e como os DNs de assunto estão estruturados, por exemplo. Conheço algumas CAs que nunca explicaram a identidade do usuário no certificado (que geralmente é público e geralmente visível durante o handshake para um interceptador), portanto, o Subject DN era apenas uma ID interna, conhecida da CA ( e possivelmente vinculado a um nome real entre o serviço e a CA por um canal de retorno criptografado ou mecanismo similar).