TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Build a tiny CA for your homelab with a Raspberry Pi

229 点作者 timkq4 个月前

16 条评论

ostensible4 个月前
This being raspberry pi absolves you from needing to buy a separate hardware noise generator: it has plenty of GPIO. For example, one can obtain entropy by sampling random noise generated by reverse-biasing a junction in a cheap pn transistor. Here is an example: <a href="http:&#x2F;&#x2F;holdenc.altervista.org&#x2F;avalanche&#x2F;" rel="nofollow">http:&#x2F;&#x2F;holdenc.altervista.org&#x2F;avalanche&#x2F;</a>. Bonus — maybe it will get you hooked on electrical engineering!<p>Btw, some versions of raspberry pi already have hardware random number number generator accessible at &#x2F;dev&#x2F;hwrng.
评论 #42761770 未加载
评论 #42762821 未加载
评论 #42764809 未加载
评论 #42768421 未加载
评论 #42761457 未加载
rmoriz4 个月前
I&#x27;m running smallstep CA in my homelab. While it&#x27;s nicely done and clearly focuses to the containerized enterprise market, its defaults are very harsh.<p>Take for example the maximum certificate duration. While from a production&#x2F;security perspective short-lived certificates are great, you don&#x27;t want to renew certs in your homelab every 24-48hrs. Also, many things just don&#x27;t support ACME but still benefit from a valid certificate, e.g. router&#x2F;firewall&#x2F;appliance web interfaces. Out of the box, the limit for traditionally issued certificates using the CLI is very low, too.<p>The default prevents expired certificates to be renewed. If your homelab does not offer a couple of nines behind the comma, you&#x27;ll pretty much have to intervene on a regular basis UNLESS you adjust the defaults. You can&#x27;t set the max duration to years, months or days but only hours:<p><pre><code> &quot;claims&quot;: { &quot;minTLSCertDuration&quot;: &quot;24h&quot;, &quot;maxTLSCertDuration&quot;: &quot;26400h&quot;, &quot;defaultTLSCertDuration&quot;: &quot;9000h&quot; }, </code></pre> If the goal of hour homelab is to design&#x2F;test&#x2F;experiment with a fault-tolerant high availability k8s infra, e.g. for your job, it&#x27;s great.<p>CAVE: macOS enforces duration limits even for trusted enterprise CAs, e.g. Safari won&#x27;t accept your 1000 days certificate anymore.
评论 #42761570 未加载
评论 #42764789 未加载
评论 #42764269 未加载
likeabatterycar4 个月前
This is littered with so many missteps I don&#x27;t know where to start.<p>-Complete overkill requiring the use of a YubiKey for key storage and external RNG source - what problems does this solve? For a Yubikey to act as a poor man&#x27;s HSM you have to store the PIN in plaintext on the disk. So if the device is compromised, they can just issue their own certs. If it&#x27;s to protect against physical theft of the keys, they&#x27;ll just put the entire Raspberry Pi in their pocket. You could choose to enter the PIN manually but this precludes any automation including CRL generation. It&#x27;s also a waste of a good YubiKey.<p>-Creates a two-tier PKI... on the same device. This completely defeats the purpose so you can&#x27;t revoke anything in case of key compromise. You could make it a 100-tier PKI and it would make no difference if they&#x27;re on the same device. Though they would need a whole lot of YubiKeys and USB hubs for that.<p>-They&#x27;re generating the private key on disk then importing into the YubiKey. Which defeats having an external key storage device because you have left traces of the key on disk.<p>-All this digital duct taping the windows and doors yet the article instructs you to download and run random binaries off GitHub with no verification whatsoever.<p>-Why do you need ACME in a homelab and can&#x27;t just hand issue long lived certificates?<p>-OpenSC and the crypto libraries are notoriously difficult to set up and working properly. A tiny CA this is not.<p>An instance of openssl or xca covers 99.9% of &quot;homelab&quot; use cases. This is like using a battery operated drill to open a can of soup.
评论 #42761004 未加载
评论 #42761003 未加载
评论 #42761145 未加载
评论 #42765934 未加载
talkingtab4 个月前
&quot;with a Yubikey&quot; is probably a better title. The yubikey thingy costs more than the PI (and there is a helpful link if you want to buy one).<p>Very little of this has to do with a PI, it seems like almost any kind of home server would work (especially linux). And it is unclear to me what value is added by the yubikey? And would any FIDO device work, or is this yubikey brand only?
评论 #42766767 未加载
评论 #42764050 未加载
pandemic_region4 个月前
Not appreciating the hijacking of the back button until the cookie form is dismissed.
评论 #42767043 未加载
nimbius4 个月前
For those interested in an hsm pi, theres picohsm <a href="https:&#x2F;&#x2F;github.com&#x2F;polhenarejos&#x2F;pico-hsm">https:&#x2F;&#x2F;github.com&#x2F;polhenarejos&#x2F;pico-hsm</a>
bpye4 个月前
Is there any way to replace the dedicated RNG with the YubiKey RNG? The OpenPGP applet allows you to query its internal RNG [0].<p>[0] - <a href="https:&#x2F;&#x2F;developers.yubico.com&#x2F;PGP&#x2F;YubiKey_5.2.3_Enhancements_to_OpenPGP_3.4.html" rel="nofollow">https:&#x2F;&#x2F;developers.yubico.com&#x2F;PGP&#x2F;YubiKey_5.2.3_Enhancements...</a>
zikduruqe4 个月前
That isn&#x27;t so tiny.<p>This is tiny. <a href="https:&#x2F;&#x2F;github.com&#x2F;FiloSottile&#x2F;mkcert">https:&#x2F;&#x2F;github.com&#x2F;FiloSottile&#x2F;mkcert</a>
评论 #42760375 未加载
globular-toast4 个月前
I wish it was easier to get your CA installed in trust stores. Even for devices you control it&#x27;s annoying but even worse if you want to share your services with mates at your house or over VPN etc. In the end it&#x27;s just easier to go with LE certs for all practical cases.
评论 #42766911 未加载
drpixie4 个月前
Bit of an aside, but the &quot;Infinite Noise TRNG&quot; seems to generate not very random &quot;raw&quot; data, which it hashes to make it appear as random bits.<p>Am I missing something, or wouldn&#x27;t it be better to start with highly random raw data, and hash that to get more bits-per-second?
throw0101c4 个月前
See also perhaps &quot;Running one’s own root Certificate Authority in 2023&quot; from a little while ago:<p>* <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37537689">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37537689</a>
kayson4 个月前
This has been on my list to implement for a while. It&#x27;s a really great idea for things like proxmox and pfsense that you probably don&#x27;t want to use LetsEncrypt for, but support ACME.
评论 #42764615 未加载
fweimer4 个月前
It&#x27;s odd that they don&#x27;t include a real-time clock. Signatures include timestamps, and those better be trustworthy.
评论 #42765467 未加载
packetlost4 个月前
I use MiniCA for this. It&#x27;s really nice
jcims4 个月前
I think a nanosat running a CA that you can directly via some kind of low cost RF channel would be a fun experiment.
bongodongobob4 个月前
I guess I&#x27;m not the intended audience, but the last thing I want in my homelab is a CA. One more thing I&#x27;d set up, forget how it works, then spend an entire weekend trying to fix when it breaks a year from now.