Vlastní SSL certifikáty

Vygenerovat si ho samozřejmě můžeš. Ale pokud nebude podepsaný důvěryhodnou certifikační autoritou, tak se to bude projevovat právě takhle.
Na svém stroji si to můžeš přidat do výjimek.

Díky, ale ani vyjímka nepomohla, nějaký jiný nápad?

Musis si verejnou cast nainstalovat do tveho pocitace a musi souhlasit pro koho jsi ho vygeneroval. Jestli pres domenu, tak musi souhlasit domena, jestli pres IP, pak musi souhlasit IP v certifikatu

Já to zkoušel a hostname v případě hostname nebo ip v případě ip sedět nemusí.
Funguje to se self-signed certifikátem úplně stejně a to i když žádná hostname nebo ip nastavená v certifikátu není.

Já si normálně vygeneroval certifikáty jako CA (certifikační autorita) a veřejný klíč hodil do prohlížeče, že jako CA.

Pak si následně s tím CA klíčem (soukromým) podepisuju nově vygenerované certifikáty pro libovolné domény a prohlížeč je normálně bere

Pokud je toto: "prohlížeč odmítá stránku načíst" opravdu pravda tak máš asi ten certifikát špatně vygenerovaný.
Když vygeneruju správně self-signed (podepsaný sám sebou) certifikát, tak mi to v prohlížeči vygeneruje varování a chybový kód (chrome/edge):
NET::ERR_CERT_AUTHORITY_INVALID
dám pokračovat a normálně to jede na https a příště ani nemusím nic potvrzovat.
Žádný certifikát si do počítače nebo prohlížeče neinstaluju.

Můj postup co používám.
openssl, vygenerování server.key, server.csr a server.crt

openssl genrsa -out server.key 4096
openssl req -config openssl.cnf -new -key server.key -out server.csr -subj "/C=CZ/ST=Morava/L=Brno/O=Krakatoa/emailAddress=admin@localhost/CN=localhost"
openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 365

V parametru subj zadám parametry certifikátu jaké potřebuju.

V Apache httpd.conf zajištěna https a http2 funkcionalita pomocí tohoto (vedle httpd.conf přiložen server.key a server.crt):

LoadModule http2_module modules/mod_http2.so
LoadModule ssl_module modules/mod_ssl.so

Listen 443
<VirtualHost *:443>
  DocumentRoot "../www"
  ServerName localhost
  SSLEngine on
  SSLCertificateFile "conf/server.crt"
  SSLCertificateKeyFile "conf/server.key"
  Protocols h2 h2c http/1.1
</VirtualHost>

<IfModule ssl_module>
  SSLRandomSeed startup builtin
  SSLRandomSeed connect builtin
</IfModule>

A normálně to funguje

... a něco jsem našel, není to tvůj problém?
https://github.com/docksal/service-vhost-proxy/issues/56
https://github.com/docksal/service-vhost-proxy/pull/57
Chrome a macOS a NET::ERR_CERT_INVALID
Nemáš macOS? Na jakém operačním systému to řešíš?
Pomohlo tam SAN and extendedKeyUsage + musí být splněny i ty další podmínky... Asi by to chtělo i zjistit aktuální podmínky pro akceptování tvého prohlížeče v tvém operačním systému.
Ve Windows to tak drsné není, ve Windows by to fungovat mělo, tedy aspoň na Windows 10 to funguje.
Pokud to řešíš na Windows tak někam uploadni ty soubory certifikátu. Nebo je můžeš uploadnout i tak, ať je jasné co za certifikát řešíš.

vidím že ti nesedí doména

smyslena-done.cz

a hostname/site, který ti servíruje data:

test.dev

Nesedí co? Zápis v hosts a doména v chybové hlášce v prohlížeči? Toto mu ve skutečnosti sedí, protože pokud by to ve skutečnosti nesedělo, co má uvedeno v prohlížeči a to co má uvedeno v hosts, tak by se to nedostalo ani k pokusu o načítání certifikátu, prostě by se prohlížeč k tomu serveru vůbec nedostal a chybovou hlášku by mu to psalo tuto:

Tento web není dostupný
Zkontrolujte, zda v adrese test.dev nemáte překlep.
Pokud je adresa zadána správně, zkuste spustit Diagnostiku sítě systému Windows.
DNS_PROBE_FINISHED_NXDOMAIN

Jen to prostě má v dotazu uvedeno nevhodně různě, ale doma tady to co se týče hosts a co se snaží zobrazit v prohlížeči má podle mě nastaveno správně.
V čem má pravděpodobně problém jsem tu už v příspěvcích popsal.
A nejvhodnější by asi bylo aby někam uploadnul ty soubory certifikátu přes které se to snaží šifrovat. Případně napsal OS, je asi rozdíl, když se to snaží zobrazit ve Windows a macOS. A taky by případně asi mohl pak sdělit nastavení serveru, kdyby se pak zjistilo, že problém nebyl v certifikátu a OS.

nesedí certifikát na site name, celkem logicky, ne?

Máš tyto komponenty:

1. resolver
2. certifkát (konfigurace apache/nginx)
3. site name (konfigurace apache/nginx)

a všechny musí sedět. Když nesedí, tak SSL bude kvičet.

Nechápu tě.
1)
V hosts má nastavenu doménu test.dev správně a připojuje se ve webovém prohlížeči na test.dev
Jen tady na poradně má v příspěvku smyslena-done.cz, což je úplně irelevantní.
Proč tomu tak je jsem ti už dostatečně vysvetlil, co na tom nechápeš???
Tak nechápu proč tady to řešíš.
2)
On ale řeší aby se mu webová stránka v pohlížeči načetla, neřeší to jestli neco bude kvičet nebo nebude. Tedy minimálně aby vyhazoval prohlížeč chybu NET::ERR_CERT_AUTHORITY_INVALID (to by se mu načetla), mu ale vyhazuje prohlížeč chybovou hlášku NET::ERR_CERT_INVALID a při té se mu to, jestli píše pravdu, nenačte, stejně jako se to nenačetlo s touto chybou tomu jedinci z odkazu, který jsem uvedl (v tom případě byl důvod omezení v kombinaci chrome + macOS ... v tom případě je potřeba dodržet určité požadavky na certifikát).
Jenže třeba ve Windows takové požadavky nejsou, ve Windows můžeš použít klidně certifikát s nesprávnou doménou nebo bez nastavené domény v certifikátu a v prohlížeči ti normálně šifrované spojení bude fungovat, jen dáš prostě při první použití certifikátu v prohlížeči pokračovat = tazatel tam to pokračovat vůbec nemá, jinak by to neřešil a nepsal to co psal. Vyzkoušej si to, já to zkoušel.
Nebo to ti snad mám udělat i screeny abys to pochopil? Klidně udělám.
3)
Jestli tím "vidím že ti nesedí doména" a "nesedí certifikát na site name" myslíš že v certifikátu je jiná doména než ta, na kterou přistupuje, tak můžu vědět podle čeho tak usuzuješ??? Doménu v certifikátu nejspíš musí řešit jen v případě, že má třeba ten macOS... a je možné, že tam tu doménu správně v certifikátu nemá, ale z toho, co tu psal, to není jasné. A ty požadavky v případě macOS nejsou jen ta doména, ale i doba vypršení certifikátu, extendedKeyUsage atd.... ale to by pak řešil kvůli macOS a jeho požadavkům (a pravidlům pro možnost pokračování v načtení stránky), ne kvůli tomu že něco kvičí. To, že něco kvičí, vůbec pro načtení šifrovaného připojení nevadí, vadí to jen pokud zrovna není ta možnost pokračovat, schlálně se podívej na ty dva linky, co jsem uvedl (github).
Příklad:
Windows a certifikát bez domény nebo s jinou doménou: prohlížeč kvičí (NET::ERR_CERT_AUTHORITY_INVALID), ale po pokračování šifrované spojení dunguje.
Windows a certifikát se správnou doménou: úplně to samé co předchozí.
macOS a splněné minimální požadavky na certifikát v macOS: podle dostupných info taky to samé co předchozí dva případy.
macOS a nesplněné minimální požadavky na certifikát v macOS: podle dostupných info to kvičí s chybou NET::ERR_CERT_INVALID a pak nejde pokračovat.
A ty minimální požadavky jsou třeba ta doména, doba expirace, extendedKeyUsage...
Jasně, doména...
Jenže ty tu kvičíš protože vidíš smyslena-done.cz (hosts) a test.dev (snaží se připojit v prohlížeči) v jeho příspěvku, jenže vůbec nezáleží na tom, co má v příspěvku, ve skutečnosti má v hosts a v prohlížeči to samé. Když už tak záleží na tom, co má v certifikátu a v prohlížeči, jenže to nevíš co tam má. A že doménu v certifikátu tam potřebuje třeba na macOS (pokud to řeší na macOS) v rámci těch minimálních požadavků jsem mu už psal (to je to SAN = Subject Alternate Name). Ve Windows to řešit nemusí, protože prohlížeč ve Windows není tak přísný.
Netuším jak jinak ti to vysvětlit

Ano, nechápeš.

Já odpovídám na to, co tu je uvedeno, ne na to, co si ty myslíš jak je. Tazatel se odmlčel, tudíž si to buď vyřešil, nebo ztratil zájem. Pokud SSL hlásí jakýkoli problém, je něco špatně a je úplně jedno, jestli se dá či nedá pokračovat, protože pak to SSL tam nemusí být vůbec, pro účely ladění zase je možné kontrolu SSL v chromu (pokud to vůbec byl chorme) vypnout zcela.

je úplně jedno, jestli se dá či nedá pokračovat, protože pak to SSL tam nemusí být vůbec

To zase není úplně pravda. I pokud nesedí doména nebo ten certifikát není důvěryhodně podepsaný, pořád ten přenos probíhá šifrovaně a třetí strana ho tak nezachytí.

Ano, za předpokladu, že klíč je opravdu tajný a nejde o nějaké řešení "mrskneme tam tento certifikát, který používáme běžně na všechny vývoje a leží tady veřejně dostupný v devkitu"

Tazatel řeší zobrazení v prohlížeči!
A ty tu píšeš: "jedno, jestli se dá či nedá pokračovat", ach jo... To pokračovat je zobrazení v prohlížeči...

"pak to SSL tam nemusí být vůbec" ... Můžeš používat šifrované https připojení. Můžeš použít http2. Můžeš zkoušet generovat certifikáty... Můžeš testovat. ... Aha, vůbec...

Mimochodem, tazatel řeší svůj vygenerovaný certifikát .-) (ne ležící)
A k tomu ležícímu certifikátu, xampp nepoužívám (a ani podobné balíčky), ale předpokládám, že na testování ho lidi používají (počet stažení za poslední týden z ofiko odkazu je 260 000) a v aktuální v necelé tři měsíce staré verzi je ležící certifikát (sha1, RSA 1024bit, CN = localhost, expirace ‎sobota ‎9. ‎listopadu ‎2019 0:48:47, bez SAN...)...

A ještě poznámka k tomuto:
"pro účely ladění zase je možné kontrolu SSL v chromu (pokud to vůbec byl chorme) vypnout zcela"
Čistě teoreticky, v případě, že by se jednalo o macOS a důvodem nezobrazení v prohlížeči by byly ty minimální požadavky na certifikát na macOS, tak pokud tam není možnost pokračovat přímo na webové stránce v zobrazení stránky, tak podle mě tam nebude ani možnost obejít ty minimální požadavky na certifikát v nastavení chrome. Nemám ale jak vyzkoušet, macOS nepoužívám.
Na Windows se to řešit nemusí, ve Windows pokračovat v prolížení normálně je a je tam i jiná chybová hláška, to jsem tu už popisoval.

OMG.
Se uklidni. To byla reakce na Wikana.

Tvé teorie mě fakt nezajímají.

Vím, že to byla reakce na Wikana
Wikan zas reagoval na příspěvek, kde jsi reagoval na mě
Můj příspěvek se ze 3/4 odstavců týká toho co jsi psal v 08.03.2023 08:16 mně, jsou tam z toho i citace. Pokud máš problém tady s tím, tak ty tři odstavce přesuň do příspěvku 08.03.2023 11:18, jsi administrátor, tak to nejspíš můžeš.
A jeden odstavec je to ohledně toho válejícího se klíče.

Ano, nechápu tě.
"Já odpovídám na to, co tu je uvedeno" = nesmysl!
Jsi úplně mimo.

Tazatel řeší:
"Vlastní SSL certifikáty ... můžu si ještě v dnešní době vygenerovat vlastní certifikát pro https aby přes něj prohlížeč načetl stránku?"

A ty tu řešíš úplně nesmyslně:
1) smyslena-done.cz (hosts) <> test.dev (prohlížeč) v úvodním příspěvku
2) (ne)kvičení ohledně certifikátu
3) (ne)potřebnost https pokud prohlížeč hlásí s certifikátem problém