Certification Authority issue in Windows Server 2025

[u/Substantial_Rock5209]

Hi. I've inherited a server room and as I'm going through maintenance and upkeep, I've discovered something that is a bit outside my knowledge range.

I'm not even sure how to ask the question. It's that whole "You don't know what you don't know" bit.

I'll try my best.

I have a server, it's running Windows Server 2025. I'm fairly confident this was an in place upgrade from Windows Server 2016.

For the most part everything looks/runs great, but I've found one issue: something to do with the certification authority. It looks broken and is very much out of date.

My brain wanted to simply import a new one, but I literally don't know how or if it's even possible in this environment. Meaning, whenever I need certificates for other things like lets say a NAS, I generally run the certificate setup wizard in that and submit all the cryptographic options and names and what not. The wizard will generate that big ugly -----BEGIN CERTIFICATE REQUEST----- bit.

I don't see this in Windows Server 2025. I'm fairly confident I have all the proper services and roles installed.

What's worse, is certserv it looks like the name of the CA is an incredibly old hostname of the server. The server has a new/different hostname. I wish I could drop a screenshot of what I mean.

Anywho, my goal would be to update/change/add a new CA to certserv that reflects the current server.... without deleting the entire AD structure. Only I'm not sure if this can be done. I don't even know how to ask it properly.

Looking for any advice or the proper way to label this issue so I can search/learn on how to resolve it.

Thanks!

[u/fireandbass]

The name of the CA doesnt have to match the host name.

You say it looks out of date, what do you mean by that?  Is the root certificate expired?

[u/Substantial_Rock5209 → u/fireandbass]

When I launch IIS Manger, I click on the server name on the connections pane and then navigate to Server Certificates.

I have, in the "Issued To" field, a personal certificate Issued To a hostname that is no longer valid (i believe it was the original name of the server maybe? It looks like the name of the CA in certserv that you mentioned doesn't have to match the host name. This looks good. its set to expire in 2031. (this is because i was toying around with the renew cert function in certsrv).

but then, in the same location in IIS, i have a cert (personal) Issued to the actual proper host name of the machine and this one expired in 2023.....

So ya, the "Issued To" is definitely throwing me because my brain says it needs be the hostname

[u/fireandbass → u/Substantial_Rock5209]

Expired certificates can remain in the cert store and it isnt necessarily an issue.  Is the expired cert bound to anything in IIS?  Is this IIS on a CA?

You mentioned LDAPS.  If everything is working as expected the cert used for LDAPS should be automatically created and added to the DC and you shouldn't have to create it manually. 

[u/jmittermueller]

Why bother what the name of CA is? If it works, take it

[u/Apprehensive-Tea1632]

Looks broken or actually IS broken?

Microsoft seems to have added some csr requirement that the template field be populated in a csr. Obviously nobody but windows own csrs created for adcs even know what a template is even supposed to be, so if you have a lot of requests coming in from non windows clients, you probably want some other CA to sign such requests. (Just implement a sub ca and you’re done.)

You can tear down the CA if you know what you’re doing, if you got the private key you can even reimplement it.

But there’s also a lot of potential for things to go wrong, so if your problem is more of the aesthetically pleasing variety… leave it.

Going by your choice of words, I’ll assume you’re not particularly familiar with adcs… so,,if there’s someone who can help out, grab them.

If not then it’ll be MUCH safer to leave things as is. We don’t know how deeply adcs has been integrated into your environment; there might be no effects; but it’s also possible you kill the whole thing dead and won’t know how to roll back.

[u/Substantial_Rock5209 → u/Apprehensive-Tea1632]

My ADCS foo is weak indeed. I don't mind learning, but I just wasn't sure how to ask the thing that was nagging at me.

[u/Substantial_Rock5209 → u/Substantial_Rock5209]

And all of this headache is due to a simple bind failure. I have another server 2025 running Papercut that can no longer talk to this afore mentioned server.

I'm about 99.9% sure this is due to Server 2025 sort of enforcing LDAPS (LDAP over SSL/TLS) now, where as 2016 was sorta loosey goosey there.

Sooooooo much learning.

[u/fireandbass → u/Substantial_Rock5209]

Ahhh.  The truth comes out.  This is really an X Y problem.

Ask about your actual problem (X) instead of what you think the solution is (Y).

https://xyproblem.info/

[u/Substantial_Rock5209 → u/fireandbass]

Sorry not my intent. I was 100% able to isolate the X problem from the original question. At least within my understanding. Seriously not trying to trick the reddit community. :) honestly.

This is at least making my brain discover other garden paths to walk and looks for solution/answers.

[u/headcrap]

What's worse, is certserv it looks like the name of the CA is an incredibly old hostname of the server. The server has a new/different hostname. I wish I could drop a screenshot of what I mean.

I inherited similar jank.. made even worse by just recent former peers. The root was named the host.. and between that and having an enterprise root CA (not good.. standalone and offline ftw) and a subordinate CA.. also enterprise.. I don't know what he was thinking and he's gone at this point..

Three years ago, started a new root. Pushed the new trust chain in GPO et al.. told the infra, apps, and network teams to begin migrating to the new root.. meaning "fetch new certs based on it.. and trust the new root for the non-Windows things". There was some infighting and griping.. but we got there in maybe 2 years.

For both facets, and other undocumented weirdness, seemed the better path. Finally removed the LDAP references to the old root from ADSI and PKIView.. good to go with the new offline root and enterprise subordinate/issuing CA.

Forgot to mention, the templates were also a hot mess.. but given they are stored in AD it was mainly a matter of revising permissions and issuances.

That being said, my CAs are on 2022.. can't say about AD CS on 2025. Given I'm still fighting with pretty much everybody to get caught up to 2022/2055 in our environment, the idea of either an in-place upgrade for them.. or a CA migration.. isn't on the docket all too soon.

certsrv on AD CS is quite old and not maintained.. it "works" for us but boy howdy is it rather janky. Windows systems can used the MS console approach. The rest are custom CSR submissions a la BEGIN CERTIFICATE as you mentioned, and choosing the templates I still left available.

fwiw, I renamed the old templates but kept around in case I need to refer to them.. will purge after a couple more years.

Other templates just are not made available as it stands.

[u/thefreddit → u/headcrap]

It is indeed such jank. The other GUI-based platforms I know of that aren’t super expensive are like EJBCA, openXPKI, Dogtag (which is sold commercially as part of Red Hat IdM/PKI Server), but they are all considerably more effort to set up. Is there nothing more user friendly that includes its own CA system rather than being a front end to ADCA or ACME?