|
The odd thing to me is that they seem to be using relatively short--
term root and intermediate certificates. I can understand having
individual certs at 3 years or less, but they seem to be doing 2 years
on their root and intermediate. They are the issuing organization, and
by only issuing certs to themselves from those root chains, they can
control who has them and when they have to be updated, but it still
seems like they are making more work for themselves than they have to.
Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Bradley Stone
Sent: Tuesday, December 13, 2016 7:07 PM
To: Midrange Systems Technical Discussion
Subject: Re: Anyone Familiar with How Server Farms and SSL
Certificates Work?
No answer from MS or any other support forums on how or why this is
happening, but I was able to put together a pretty neat little system
using DOS batch files, openssl and the IBM i to constantly log into
their servers with openSSL, saving the Cert retrieved over and over
every 5 seconds. I then compared the certs with one I already had
until I found one that was different and was able to extract the other
set of CAs. It took over 2000 hits for it to finally find the differnent cert.
But I got a few in a row after that.
I'm going to put an article together for it soon just because it was
such a headache. MS... I was always indifferent about them, never
having all these "problems" with Windows like its hip to talk about...
but this was their cloud services... if they can't help paying
customers, I will seriously never recommend their cloud services over
Google's.
Insert in pipe, and smoke. :) Time for a scotch.
Brad
www.bvstools.com
On Tue, Dec 13, 2016 at 8:55 AM, Bradley Stone <bvstone@xxxxxxxxx>
wrote:
I am posting this hear so hopefully someone with some experience can
help me possibly understand what Microsoft's servers are doing.
So, randomly their email servers are presenting different SSL
certificates to clients when they connect. If the certificate used
is
one that we haven't imported the Certificate Authorities (CAs) for,
we
get an not trusted error on the IBM i.
Normally for this type of thing we simply use openSSL to grab the
CAs and import them using DCM. But because it's random, and the
server(s)
that are presenting this odd SSL cert we can't purposely connect to,
it's been a whole day of trying to get this rogue SSL certificate
(hopefully it is only one more!)
The same thing is happening with the RESTful API servers. I got
lucky
with openSSL on these and was able to get both certificates so that
at
least for those using the API are ok for now.
But the smtp server is another story. I haven't been lucky enough
to get the other certificate.
How and why would this be happening? When they install a new SSL
cert
does it get replicated to all the servers in the farm? Or is thatall... or "yet")?
don't manually and it's possible a couple didn't get updated (at
I've tried contacting MS but so far nothing from them. I just want
to
know if what I think is happening is in fact happening.more stable.
BTW, if you're on the fence between using Google or Outlook 365 for
your corporate email in the future, after dealing with both for a
few years I would pick Google over MS every time. It's faster and
much
(just a vent there... haha!)--
Brad
www.bvstools.com
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
