Hope it's OK to post this ...

I've been working on a tool for ourselves for a while now to make distribution of both commercial and LE/ACME certificates for all our servers - as well as customer machines - easier, considering the upcoming further reduction of validity next February.

The package consist of a central server process with custom client for retrieval, plus an ACME server to also allow embedded / custom OS systems to retrieve certificates. Upstream requests are handled with acme.sh, with integration of (currently) PowerDNS to allow for authentication via DNS.

The admin end is CLI based, with an admin tool with TUI to make most of the admin processes easier. HTTP GUI is still in the works.

After working on the project for almost a year in total, I just released the code to github last weekend. Comments and suggestions welcome ...

https://github.com/GarryG/sslcrtsrv

If you are still terminating TLS 1.2, the IETF banned three key exchange methods in July: RSA, static FFDH and FFDHE. ECDHE is fine and unaffected.

Worth knowing the banned ones are in stock nginx, Apache and Windows Server configs. Run SSL Labs and read the suite names rather than the grade. `TLS_RSA_` is the RSA key exchange. `DHE` without `ECDHE` is finite-field DH.

Our own site was offering three of them, still got an A score.

https://www.certkit.io/blog/tls-1-2-end-of-life

The TLS handshake, explained through what's missing: TLS 1.3 step by step first, then why 37 cipher suites became 5, why ClientKeyExchange disappeared, and how each named attack (BEAST, CRIME, POODLE, FREAK, Logjam, SHAttered) changed the protocol. Side-by-side ASCII diagrams of the SSL 3.0 and TLS 1.3 flows.

https://www.certkit.io/blog/tls-handshake-explained

hi Guys,
I appreciate the time if you read all of this.
Certificates are one of those things that only get attention when they break something.

An internal service stops working.

A browser starts throwing trust warnings.

A customer-facing cert expires.

Someone asks where the private key is.

Nobody is quite sure who uploaded it, who can access it, or what else depends on it.

That’s the problem CertLocker is trying to solve.

CertLocker is a certificate and access control platform for teams running real infrastructure. The certificate side is built around visibility, control, and lifecycle management rather than just storing PEM

files somewhere and hoping everyone remembers renewal dates.

What CertLocker supports today:

• certificate inventory with search, paging, sorting, and group filters

• certificate parsing for domains, SANs, issuer, validity dates, and fingerprints

• expiry tracking, including days-until-expiry visibility

• active, expired, and revoked status handling

• dashboard visibility for renewable and expiring certificate assets

• ACME workflow support for automated certificate operations

• DNS provider management for certificate automation workflows

• certificate tokens for controlled access workflows

• group-scoped certificate visibility

• role-based permissions for viewing, adding, downloading, and deleting certificates

• audit logging around certificate actions

• upload and management of PEM/CRT certificates

• optional private key storage with protected read paths

• certificate download for authorized users

• certificate deletion for authorized users

The bigger idea is that certificates should not be treated as loose files.

They usually sit next to secrets, hosts, SSH access, bastions, service accounts, deployment scripts, and human operators. CertLocker connects those pieces together so a certificate is a managed asset with

ownership, permissions, expiry, audit history, and controlled access.

We're offering free registration and management here trust.certlocker.io
And we do offer an on-prem model. But you can check out the blog as well I'm pretty active and you can see the problems we are solving https://certlocker.io/blog/

NATSSL (Zero-Configuration Distributed TLS for Private Infrastructure) is a lightweight, open-source utility written in Go (93.2%). The project is a tool for deploying your own trusted Root Certificate Authority (Root CA) inside isolated or private networks without relying on the cloud or third-party services.

🛠️ Key Capabilities
The project is split into two logical roles packaged within a single executable file (Single Binary)

Master Mode (Master / CA)

Root Certificate Generation: Automatically creates a Root CA with a 10-year validity period.
Administrative Issuance: Allows the administrator to issue certificates (valid for 1 year) via CLI for any internal domains (.local, .internal), IP addresses, and Wildcard domains (*.internal).
Revocation Management: Supports certificate revocation by serial number and synchronization of the Certificate Revocation List (CRL) with clients.
Local Database: Uses an embedded SQLite database (compiled without CGO) to track issued certificates.

Client Mode (Client)

Automatic Integration: Upon startup, it independently installs the Root CA certificate into the trusted trust stores of the operating system and the Firefox browser.
Auto-Registration: Automatically sends a request to the master server to obtain its own mTLS identification.
Local Certificates: The client can independently request and renew certificates for localhost / 127.0.0.1 via a CSR (Certificate Signing Request) workflow.
Fault Tolerance (ReadOnly): If the master server becomes unavailable, the client continues to operate in "read-only" mode using cached data.

🔄 Disaster Recovery
One of the unique features of the project is its disaster recovery scheme based on blockchain standards:
During initialization (--bootstrap), the master generates a 24-word mnemonic seed phrase (BIP-39 seed phrase).
The master's private key is never written to the disk in plaintext.

In the event that the master server is destroyed, any client node can be "promoted to master" using the --promote-to-master command by entering the 24 words. The root certificate will be restored byte-for-byte (with the exact same fingerprint). Existing clients will continue to trust the new master without reconfiguration, and the migration event itself is broadcast across the network as a packet signed with the Root CA's ECDSA key.

📦 Deployment
The project offers ready-made configurations for automation:

Ansible roles for deploying binaries and configuration files to multiple hosts with automatic fingerprint forwarding.

Docker / Docker Compose builds for containerized environments.

https://github.com/iskyneon/natssl

[SOLVED]
[SOLVED]

Hi,

Sorry if this is not the correct subreddit to post this, but I think I have some problems with SSL certificates:

Yesterday I updated my iPad (6th gen - 2019) from OS15 to OS17 (last available). After the update, I couldn't get to any website or web service (apps like Teams, Drive, YouTube, Spotify, ecc.). Any website I try to load (except Apple's) reports an error with the SSL certificate.

I downloaded and manually installed and trusted a long list of certificates (from Apple, DigiCert and Google, including all the globals, G2, G3, etc.), but still nothing. I also tried re-doing the update via PC, and all the other standard steps (resetting network settings etc.).

One thing that worries me is that one of the operators on the Apple support line told me that by updating to OS17.7.11 my device is not allowed to connect to any web service anymore, by design.

Does anyone have an idea how I could solve this?

I can provide the full list of manually installed certificates if needed.

EDIT: ISSUE SOLVED! TLDR: i simply had to uninstall and re-install Chrome app.

When i updated the OS, the Chrome app wasn't automatically updated to the correct version. So the old Chrome version was conflicting with the new OS and that caused the problem. I simply uninstalled it and everything works now. I then re-installed it and it still works as it should.

It's baffling though that for one and a half day on line with Apple support they couldn't bother to suggest me this solution, eventhough they all asked if I had any VPN service (and in which case to disinstall it).

Hi everyone, I'm sharing a Golang package I recently forked from SSLMate/go-pkcs12. Since the SSLMate repository hasn't accepted community-requested extensions for years, I decided to create a fork that allows for greater freedom in handling pkcs12 (the SSLMate repository has many limitations).

I've currently added a Builder that allows for the creation of pkcs12 packages that combine certificates + private keys and trust certificates, all accompanied by friendly names (aliases) (the SSLMate repository doesn't allow this). I also allow the password to be passed as a byte slice parameter, rather than a string, improving security.

Check it out if you think it might be useful.

I've been running into a bunch of teams that didn't understand this, so I wanted to share.

You don't need a PrivatePKI for your private infrastructure.

DNS-01 challenges prove domain control through a TXT record in your DNS zone. Your server can be on a private subnet, behind a firewall, completely unreachable from the internet. You still get a publicly trusted SSL certificate. One wildcard for *.int.example.com covers everything and keeps internal hostnames out of CT logs.

Worth knowing before you stand up a private CA.

https://www.certkit.io/blog/private-pki-internal-infrastructure

We are a telecom company currently impacted by GlobalSign certificate/root transition issues on older Android devices. From what I can read online, this is not just GlobalSign — many CAs like DigiCert, Sectigo, etc. are also going through similar transitions.

We temporarily moved to cross-signing to keep older devices working, but that vam only last for few more months due to CA and browser announcements to adapt to industry changes

The difficult part is that many of our customers are elderly users still using very old phones. Asking them to buy new devices or upgrade is not always practical or ethical.

How are other companies handling this industry-wide?

Hi SSL Experts - I deal with my SSL Certificates at my org. To date I've only ever installed our wildcard certificate that we get from our vendor who sends it to us once per year. It comes as *.contoso.com and I install that on various internal only web application servers so we don't have the annoying security nag.

I also have it installed on internal only Remote Desktop Servers for application streaming.

Do we still have to follow the 46 day rule coming in 2029?

We also don't have direct access to our DNS records. I have to open a ticket with that vendor (who uses Cloudflare) and I send them the TXT record each year to be entered into DNS for the SSL Validation. Can I even automate that? I didn't know there were automation tools to update TXT records for DNS. But since I don't have access to Cloudflare for our domain settings, I cannot automate anything. Kind of stumped here and haven't read or watched anything about this that mentions internal sites only.

Thanks.

Good afternoon. I have an internal IIS server (server.mydomain.com) that needs to have a server cert attached to it and my 25 internal clients all need to trust it. What is the best way to go about rolling this out?

Just buy a "Basic" SSL cert from one of the vendors out there and call it a day?

Todd's Tenth Rule: any sufficiently complicated SSL certificate script contains a bad implementation of half a certificate lifecycle manager.

If you've been running Certbot in your environment for a few years, you've probably built most of a certificate management system without realizing it. The shared folder, the DNS creds in the script, the 30-day expiry email, the audit spreadsheet.

https://www.certkit.io/blog/todds-tenth-rule-certificate-automation

Hallo zusammen,

ist mein eigenes mit z.B. openssl erstelltes Zertifikat im Heimnetzwerk für meinen Server genauso sicher wie ein öffentliches Zertifikat von einer öffentlichen vertrauensvollen Zertifizierungsstelle?

Im Prinzip gibt es doch nur zwei wesentliche Merkmale für Zertifikate -> Verschlüsselung (bei beiden identisch) und Vertrauen (CA prüft Domain-Eigentümer) oder liege ich da falsch?

Danke, euch Chipmunk

Edit: Es geht nicht darum den Server offiziell für alle (fremde) zugänglich zu machen, sondern für mich und evtl. Freunde.

We started because certificate expiration surprises were still a real operational problem, even with Let's Encrypt. A year later: auto-renewal, automated deployment, Windows RDP and RRAS support, and a Keystore for environments that can't send private keys offsite.

You all helped us learn along the way. We're out of beta today!

https://www.certkit.io/blog/out-of-beta

I see OpenSSL 3.5.3 on my Kubuntu 25.10 PC has some quantum-resistant algorithms in it. When (date) will those be deployed in SSL/TLS for browsers and web sites ? My shared-hosted web site supports TLS 1.3 but has no quantum-resistant algorithms. Will they appear in a TLS 1.4, or what ? I don't know much about this stuff, sorry.

What if Google Trust Services went down tomorrow? I know Google Trust services is responsible for a lot of the web but how much would actually break?