HTTPS local entre runtimes
Disponível no LaraEnv 0.5.7.
O LaraEnv preserva a CA local existente. Um par de certificado/chave parcial, inválido ou incompatível passa a produzir um erro de recuperação, sem gerar outra CA silenciosamente. Restaure os arquivos originais correspondentes; remover uma CA confiável não é um reparo automático. A política de confiança no Windows continua distinta entre edição instalada e portátil.
PHP
O bundle extras/ssl/cacert.pem mantém suas raízes e recebe o certificado público da CA local uma única vez. Diretivas curl.cainfo e openssl.cafile vazias ou gerenciadas são configuradas; caminhos personalizados ativos são preservados. Um bundle pequeno válido não é substituído por causa do tamanho. Um bundle existente inválido é preservado e reportado. Apenas a ausência do bundle usa o download Mozilla existente.
A atualização ocorre na inicialização, instalação do PHP e criação de certificados locais. Ao mover o ambiente, somente caminhos reconhecidos como gerados pelo LaraEnv são rebaseados. Se usar outro bundle explicitamente, adicione a CA pública local a ele. Nunca inclua a chave privada. Reinicie os processos existentes depois de alterar a confiança.
Node e npm
Novos terminais locais e de agentes, servidores Dev, workers de fila e crons recebem o caminho público por NODE_EXTRA_CA_CERTS. Uma variável existente é preservada, inclusive vazia ou com capitalização diferente. A preparação não modifica o ambiente do processo pai nem a confiança global do Windows. Configurações explícitas do aplicativo/npm continuam prevalecendo. Shells SSH remotos ficam fora dessa integração.
Laravel Vite
Em checkouts Laravel com HTTPS servido diretamente pelo PHP, novos processos podem receber VITE_DEV_SERVER_KEY e VITE_DEV_SERVER_CERT. O LaraEnv verifica o suporte do plugin instalado, o hostname, o par certificado/chave e sua cadeia local. Não altera vite.config, .env ou o código do projeto.
Variáveis de certificado herdadas ou presentes nos arquivos de ambiente têm prioridade. APP_URL conflitante, plugin ausente, certificado indisponível, projeto pausado ou checkout sem rota HTTPS impedem a configuração automática. Modos personalizados também são inspecionados de forma conservadora. Quando APP_URL está ausente, apenas o processo filho recebe a URL HTTPS local.
Projetos com upstream HTTP de proxy reverso mantêm sua configuração Vite. Mudar esse upstream para HTTPS exige coordenar proxy e HMR; exportar apenas os certificados quebraria o encaminhamento. A confiança Node continua sendo aplicada.
Escopo da CA e validação
Esta mudança preserva o escopo DNS das CAs existentes e novas. TLDs e aliases são configuráveis; restringir a CA a uma lista fixa exige um fluxo explícito de regeneração, substituição de confiança e recuperação. Essa migração continua pendente.
Os testes usam CAs temporárias, servidor TLS em loopback e cliente Node real. O bundle PHP é verificado em um handshake TLS pelo verificador Go. Chamadas de confiança Windows são substituídas nos testes; nenhuma CA ou runtime real do usuário é alterado. HMR no navegador e configurações externas continuam exigindo testes de integração.